This is the argument I might have expected and would have more readily accepted. If the database changes so often that it makes keeping the domain objects up to date a nightmare then it is harder to justify. There is a flip side though. Without any domain objects then the application is getting hard coded to index positions in an array or collection of values or looking up values from a map. In the specific application I am working with it is an array of Strings regardless of what the underlying values are and so if I actually want to work with the data it involves parsing it first from a String at a given index (which is also fairly fragile). Still even this could be improved upon if the array of Strings were changed to an array of Objects. The toString() method can be called on any Object to make it a String again as needed but at least some type data gets preserved that way.
On Dec 21, 3:09 pm, Steven Huwig <[email protected]> wrote: > 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 > > athttp://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.
