Troy Gilbert wrote: > 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... >
No I didnt. Perhaps you missed what I was getting at. I'll try again. The model doesn't know anything about the controller. That was my point. It does not notify the controller at all. Why would it? Here is how I see it. Communication is between the view and the controller.(gestures) Communication is between the model and the view (bindings) >> 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). > Interesting. Can you outline a benefit to your approach so I can get a better idea of the motivation behind it? The problem I see with that approach is that you cant reuse your model amoung many applications without duplicating a lot of business logic. As the functionality(logic) is located in your controllers. I guess you could reuse the controllers aswell if they were designed for that. cheers, shaun
