"Oh, we'll solve that. From now on the first String is a version of the table."
On Wed, Dec 21, 2011 at 1:45 PM, Carl Jokl <[email protected]> wrote: > 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. > -- 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.
