I've never been terribly clear on this concept and I seem to recall reading a thread a while back when several experienced WO people had different definitions of M, V and C. Is there a definitive reference on this I should read?
Whenever I'm unclear on such a technical subject, I usually go to Wikipedia for the first step at understanding. Try:
http://en.wikipedia.org/wiki/Model-view-controller
The article gives several other references for Model-View-Controller (MVC) and ostensibly cites the original source of the concepts. I've come to know about MVC primarily through WebObjects, associated documentation and discussions. I wouldn't dig too far in that direction yet. I think it's sufficient for now to know that Model objects are used to model the problem domain, whatever that domain is. Any code dealing directly with the problem domain should go in the Model classes.
So, for instance, if your system is a banking system, then you should expect model objects like Account, Deposit, Withdrawal, Depositor, Bank and such. The methods in these classes should reflect the bank's policy and should effect that policy in the system.
View objects should provide the application user's view into the data of the problem domain. In particular, there should be a very clear separation between Model objects/methods and View objects/methods. Code used to maintain and change the Model data should go into the Model classes. Code used to view that data should go into the View classes. Code to synchronize and coordinate those two types of classes should go into the Control classes.
In a WebObjects application, the Model code starts with the EOModel whose entities should reflect real world entities, whose attributes should reflect the characteristics of the real world entities, and whose relationships should reflect the relationships among those real world entities, at least so far as they are significant to the application.
The View objects start with the WODynamicElements and WOComponents. You can, and will, provide your own custom view objects, but you should avoid putting code in them that directly depends on some aspect of the Model objects. WOComponents are typical View objects, as are WOTextFields, WOBrowsers, etc.
The Control objects in WebObjects start with Application, Session and DirectAction. Customize these as much as necessary, but avoid putting View code or Model code in them. There are those who will say that WebObjects isn't pure and that there's a lot of Control code in the WOComponents. I think that's less important than the fact that the distributed WOElement classes and the basic WOComponent class are all pretty much pure View classes and don't muddy the water to begin with.
Satisfy your curiosity, but for now, there is little more that you need to know about MVC. WebObjects is built up around it, so as you gain experience with WO, you will naturally gain a feel for MVC.
Comments