Ouch. I hadn't really considered arrays of strings addressed positionally. I had imagined maps of strings (data element names) to values. This sounds pretty awful -- good luck.
On Dec 21, 2011, at 11:45 AM, 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.
