--- In [email protected], shaun etherton <[EMAIL PROTECTED]> wrote: > > 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? >
Yes the model knows nothing about the controller, but the model can only tell the view the data has changed. Here is one scenario where the controller would need to know about the change as well. If the view needs to change to a different view based on the new data. Because the view can only respond to data changes for the type of data it handles. The controller changes between different types of views. In my app we have a basic ItemType and from that there are specialized types, like collection and asset. So from a collection we can ask the controller to get an item from the collection which could be an asset or another collection. At this point we don't know what kind of item it is, we could but sadly we don't. So the controller sends the query to the model and sets the view to a loading state. When the data is received the controller is notified and resets to the correct view, then the view is notified. In this case the communication from the model to the controlled exists but the model technically does not know anything about it. It merely dispatches an event and doesn't care who listens to it. Another reason my app needs this type of communication is because the controller often needs to request other types of data in response to the data received. I could have my view do this, but in my opinion the view should be dumb. The view should just display information not manage it's retrieval. > Here is how I see it. > Communication is between the view and the controller.(gestures) > Communication is between the model and the view (bindings) In the Java Blueprints they have the view sending State Queries to the model, I don't like that because it adds intelligence to the view. The view really needs to be for display only. But I do realize that this is really the Presentation-Abstraction-Control pattern that I use and describe to some extent. > > >> 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. > I agree, business logic should be for the most part with the model unless your controller is abstract enough where it can be reused. An example of why I think this, say your data is in a SQL database and you write your controller in java. And you put all your business logic in the controller. But then you have to built a controller in a .NET environment, don't ask why it's just an example. Had your business logic be part of stored procedures then building that controller would be much easier. > cheers, Cheers was a great show, I still watch it from time to time in syndication. > shaun >
