|
Title: How do people handle command class pollution? Post by: joe on March 11, 2008, 08:51:43 I was just wondering how other people working on large applications deal with the class pollution from having tons of small command classes?
Basically we don't want to be accessing proxies from mediators and would rather have all of the logic done in commands, otherwise it really dilutes the purpose of even having commands imo, I would rather deal with centralized logic. Now saying that, how do you handle having 100s, if not 1000s of command classes in your application? Do you try to cut them down to 10-50 core commands and then use the "type" in the command and switch off that? I have tried this but it couples the mediator with commands a little as you have to know the type you are firing, it can no longer just be a basic registration. I would love to hear how others solve this issue. Title: Re: How do people handle command class pollution? Post by: theFlashWizard on March 12, 2008, 04:22:36 Seperating it into seperate/multiple pureMVC's helped us :)
There now is a Mutliton version made by Cliff and I made a non singleton/multiton version. Title: Re: How do people handle command class pollution? Post by: puremvc on March 12, 2008, 05:48:10 Having the mediators talk to proxies foer simple get/set operations or method calls is one way.
If there is actual business logic, coordinating the view model interaction in such a way that it involves several other actors, then push that into a Command. If its domain logic, that is keeping the data model integrity rather than coordinating view / model interaction) push it into a proxy. Some coupling between the view and model are inevitable, the view has no other job in life but to represent the model and let the user interact with it. You can use scads of commands to try and maintain maximum separation of view and model but at the expense of a much larger and less managable project (the genesis of your question). IMHO, the most important separation to achieve is that of the model from the view, not the other way around. That is to say the model should optimally know nothing whatsoever about the view. This allows you to reuse the model in another app. Say an admin app and a user app sharing the same model but with different a view aparatus and use cases. The obverse is not so easy change the model, and it will almost certainly involve refactoring the view and controller regions of your app. Its hard to completely insulate the view by use of commands. And its not often the case that you're needing to reuse view component/mediator pairs. It does happen but not a lot. So calling retrieveProxy from a mediator to grab the data and set it on a view component isn't such a big mvc foul really. -=Cliff> |