On 3/27/07, shaun etherton <[EMAIL PROTECTED]> wrote: > Troy Gilbert wrote: > > Brett, > > > > Events are actually an a pretty fundamental component of an MVC > > implementation. Events are most often used by the model to notify the view > > and/or controller of changes (Observer pattern). > > Usually the model does not talk to the controller (see the diagram at > the java blueprints url below). >
Uhm... you quoted exactly what I said. The model uses the Observer pattern to notify the controller (or anyone) of changes. Nothing wrong there... > The model should just be made up of objects which are modelled on the > business processes and should adhear to the usual best practices. > Properties represent state, methods implement behavior to modify state > based on some business logic. > > Therefore, the model should define the state and business > logic(behaviour) to manage the model's state. > > The ModelLocator(Cairngorm speak?) should not contain functional > methods, because the ModelLocator is not the model, its just the locator > of models. I guess this is where I may diverge from the usual practice of the model... I treat it like a RecordSet (to use Design Pattern terminology)... just data and relationships. You're right, though, that many people treat the model as a Domain Model (with accompanying methods), though I move that stuff into my controllers (and do end up with a hierarchy of controllers acting on controllers). Troy.
