After a bit more research, I realized that what I was doing was what Martin Fowler calls "Anemic Domain Model", i.e. it's just plain-old-data with no behavior/logic. Following his arguments I totally agree, it's really wasting the potential of the data model by taking that route. You end up (like me) pushing much of the model's logic into your controllers (which I have done) which complicates things when you what to reuse your model.
Of course, this hasn't really bitten me in my current project because the model is really just a typed representation of an XML document, which is just plain-old-data itself. So, my design already implicitly assumed the model was anemic! ;-) I have tweaked my ways slightly... thanks to the suggestions here! ...and have put some logic into the model that I found myself repeating. Fortunately, my model doesn't have a lot of intrinsic behavior or business rules it has to enforce, so that's nice, but I could see where it would in other scenarios. And in regards to the Observer thing... yeah, like Paul said, I've got situations where my controllers maintain some cached state based on the model that needs to be updated/rebuilt when the model changes, so the Controller does "watch" the Model (which, in Flex, ends up meaning that the binding mechanism compiled into the model -- implicitly with the binding metatag -- is sending events). Troy. On 3/29/07, Paul DeCoursey <[EMAIL PROTECTED]> wrote:
--- In [email protected] <flexcoders%40yahoogroups.com>, 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 >
