The point is that I accept the down side of the domains is that you have to add attributes to your domain objects or change them whenever your table changes. This can be a lot of work if you table is changing all the time. The positive side can be if these domains are more than just dumb data container but actually have some functionality in side them that can work on the data.
I might favour a map of Objects by String keys so that number wrappers and dates can be supported. Perhaps I might be successful in getting that much of a change. I wonder if the argument against could be the extra overhead of looking up values in a map vs the speed of looking up at a given index. It may not make that much performance difference but a map lookup is slower. However on the other hand it is less fragile. Perhaps an object that has an array of the column names and a list of maps of Strings to Objects for the row values. The column names can keep the values in the right order when doing arbitrary display of tabular data in the same order as the query results. On 21 December 2011 16:55, Steven Huwig <[email protected]> wrote: > 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. > > -- 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.
