How useful is a 'pure' MVC implementation?

Question

I work at a company that provides custom made 'CRM'-like software. We are currently redesigning/redeveloping the software with the hopes that it will look more modern and be easier to develop and customize for future clients. Currently it takes a long time to customize each new application.

There is a presumption that the reason it takes so long is because of the amount of business logic that is present in the 'view' layer. To some extent I can vouch for this being true, but symptoms don't always reliably point out a cause. There was a suggestion that if we just move the business logic to the controller layer and use pure view (we use java J2EE and struts) as in implementing struts tags instead of calling the bean layer and iterating objects right on the jsp - etc etc.

Before I start advocating we go forward with this, I wanted to get a feeling for what other people thought. Does a "pure" implementation of the MVC (especially emphasis on decoupling the controller and the view) provide a cleaner, easier to develop and change code base?

Thank all of you for the input - that has helped alot

Answer 1

Decoupling always does that. Doesn't matter, MVC or not, the less coupling there in the system, the easier it is to maintain and change. MVC is just good pattern for Web, that simplifies decoupling, that's all.

Answer 2

Someone said this:

"Any problem in computer science can be solved with another layer of indirection"

But I don't remember who is the author of this quote. Anybody knows?

Answer 3

MVC suggests that intelligence be segregated appropriately.That implies, the view and model would be kind of dumb and controller is the actual smart guy. This implication lets us create modify dumb fellas and smart guys in a smooth fashion. These benefits are reaped hugely when the requirements/code-fixes are effectively on. The added abstractions are a pain until one gets a grasp of the patterns used. This is MVC on server side. What about MVC on client end code?

At times it is very true that view models have a different intelligence built into them and are coded into business delegates. However a better approach is to use custom tags. The most annoying thing about jsp pages for me occurs when they mix up javascript with the code, This smart code actually tries to manipulate DOM and results in unmatched tags in static jsp code.

As you have the luxury to start from scratch. Life would be simpler if everyone used unobstrusive javascript (a different language from java and easier than the shit I have seen in production code) and custom tags (not that difficult). Another pain point is not having W3C compliant html/css. A huge trouble saver with browser issues, if you what they are.

P.S: Appologies for the long rant :)

Answer 4

I work at a company that follows MVC pretty strictly and we've had a lot of success with it. We've been able to develop core services that live in the controller and re-use those on multiple projects. Have the controller layer also facilitates unit testing and code re-use as well.

Answer 5

Your goal should be to get your business logic in one place. In my experience, if you can do that, your code base will definitely be easier to develop, maintain, and change.

Model-view-controller is definitely a way to get to that point, though in classic MVC, the business logic is in the (domain) model, while application logic is in the controller.

Application logic: if the user's next inspection date is within a week (or past due), show the 'schedule inspection' screen, otherwise show the 'inspection history' screen.

Business logic: restaurants that have previously failed inspection need to be inspected every six months, seafood restaurants must be inspected every year, and all other restaurants have to be inspected every two years. Given this restaurant's last inspection, when is their next inspection due?