On Wed, Dec 21, 2011 at 6:24 AM, Carl Jokl <[email protected]> wrote: > 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.
I think you are correct. I'll agree with others who have stated that this is not specific to MVC. MVC is simply an attempt to keep the proper separation of concerns. In your current system how do you perform maintenance? IOW, how do you verify that one component is working correctly as you make changes? A "0-layer" approach means you pretty much have to wait till you're done coding it, fire up the system in a test environment, and run it to see if it works. A layered system allows you to build test cases for each part and test it completely separate from anything else. This helps you to isolate problems. It also helps you to have confidence when moving from one thing to another that the thing you just wrote really works. In our world we've duplicated some demo data that we use for our unit tests. We also use mock objects to imitate this data as it moves through our system. So as we work on each piece we can work on it in isolation and verify how it reacts to real world situations. We've also built a good set of test cases over the last couple of years to catch a lot of regressions. Now I can have confidence when I do a refactor that, as long as the system still passes the set of test cases we've built, the refactor is good. This is very difficult to do in a non-layered architecture. You really can't have that kind of confidence as you're working. Developers then don't really know how to estimate progress because they don't know how far from being "done" they are with a task. So everything looks rosy until the final few days before a release when no one can seem to get anything to work. At least that's my experience. So my main arguments for separation of concerns are 1) confidence in each piece in isolation, 2) better regression testing, 3) more accurate progress reporting, which leads to 4) better project management. If there's a downside to this approach it is that all the test cases take a long time to write. However, I'd argue that it's still quicker than blind debugging where you really don't know what affect your changes are having until everything is done. The difference is that you will learn to estimate the time it takes to write tests. You can't estimate the time you'll spend fixing bugs. HTH, Greg -- 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.
