My opinion is that the term "MVC" is often misapplied to simple separation of presentation from program logic. Moreover, it's an architecture that doesn't actually need to be reflected in the code structure of typical web applications. In a web application, the browser is the view, the web server is the controller, and whatever backend code there is is the model. There's often no need to try to subdivide the backend code into MVC again, because the backend code should be leaving presentation up to the browser. Sure, it's good to keep formatting separate from database updates, but that's not the same as trying to shoehorn the whole system into one pattern from Smalltalk that's been extended past its original scope.
As far as domain objects go, "too many classes" isn't a very good objection. "Too many places to change when changing a single feature" is a better one. I have to admit that every web application that I've seen that used domain objects wasn't better for having used them. That's because business requirements for display, logic, and workflow were always changing, and solidifying these things into domain objects would only make things more complicated to update. The tradeoff that the business was making for such flexibility was having weaker interoperability and brittler business logic and automation. Thanks, Steve On Dec 21, 2011, at 7:24 AM, Carl Jokl <[email protected]> wrote: > I would like to sanity check my opinion a bit regarding MVC matters. > > I have just had bit of a discussion with my technical manager > regarding the use of domain related objects and how they fit into > Model View Controller. I had been trying to create a demonstration > domain class that was something frequently used in the system. > > The existing system does not have much of any model to speak of. The > model if anything would consist of Vectors of String arrays that > represent rows of results returned from a query. > > This is very generic in the extreme but it makes me feel like there > ought to be some domain objects in the system. > > The domain objects would be the model with the functionality related > to what the domain objects represents being in the objects in close > proximity to the data that they work on. > > My technical manager caught on to the fact that I had been working on > this code and didn't really approve failing to see what benefit it > would bring. > > I tried to give some arguments as to being able to keep data an > functionality close together in a logical place an to try to avoid > duplication of code. > > The discussion did not go well and I was left pretty deflated. My > technical manager does not believe in the use of the model view > controller design pattern. He also doesn't like the use of domain > objects either as he sees it as dramatically increasing the number of > classes in the system. > > I have not come across someone who is against the model view > controller pattern and so was not really prepared for that. I don't > know what I should do or how I could better defend MVC. MVC to me > improves cohesion of a system which each class having a well defined > responsibility rather than big bloated classes where the classes > contain model, view and controller functionality all mixed together. > > Are there really arguments against MVC? > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
