Hey Bjorn, Bjorn Schultheiss wrote:
> It took me a while to grapple with but thats how it's been explained to > me. > > VO's. Thats it. > All logic is in the commands. > > Now excuse me if I'm wrong and I'll be happy to be proven so. Interesting, but that doesnt really meet the definition of MVC does it. I'll quote the Java BluePrints: http://java.sun.com/blueprints/patterns/MVC-detailed.html . Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model. As you can see that is quite different from the DTO/VO pattern(which should be used for coarse grained data transfer). I'll quote the Java BluePrints again: http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html . Clients usually require more than one value from an enterprise bean. To reduce the number of remote calls and to avoid the associated overhead, it is best to use Transfer Objects to transport the data from the enterprise bean to its client. > In terms of event handling well, if a VO is Bindable is that the same? > Do you mean listening to the view or commands? > I do make by domain objects Bindable and non Dynamic. But I'll try and give a simple example of what I meant. My Model classes handle the propertyChange event so when a proprerty of the object changes I can set a "dirty" flag to indicate that the object has been changed and is unsaved. I also use event listeners on a collection object within a model object. Object A has many B objects(stored in an arraycollection in object A). When a B object is added to the collection, A should be flagged as unsaved. The A object needs to know when a B object has been added or removed so it can set its own "dirty flag". Object A adds a changeevent listener to its arraycollection of B objects, A handles the collection change events dispatched by the collection of B objects by setting its own "dirty" flag. Right or wrong, this is an approach I have used in the past. > I'll quote Jesse again. > > http://jessewarden.com/2007/08/10-tips-for-working-with-cairngorm.html > 3. Only Commands set data on the Model; you can break this, just don’t > if you can help it. > In Model View Controller, only the Controller sets data on the Model. > In this case, the Commands are the Controller (usually), and as such, > setting ModelLocator data is their job, and their job alone. If data is > getting f’d up, you immediately know it’s in the Command. You never > have to question “who’s setting my data, where, and when?”. I think this type of "rule" might be more beneficial if you have a VO only model, as it makes sure your logic is in one spot, the command class rather than the view. So it seems like all the Event/Command classes have to be created to make up for the deficit of logic in the actual Model - where it should be IMO. It seems like the Command, which is meant to be a Controller? according to the quote above (although we have a Front Controller aswell! Whats up with that picture?) is playing the role that the model should be. Seems bogus to me.. :) cheers, - shaun -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
