The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

When building web applications, everybody seems to be using the Model View Controller (MVC) pattern. We all use it. It’s a fundamental pattern. However, a lot of people use it incorrectly. Actually, in my six years of programming, I have never seen it done the proper way. From what I’ve seen, the majority of the MVC implementations have a major flow: too much “model” in the controller. That’s a critical error and a no-no in proper usage of the pattern.

So how should it work? The critical thing is not to have any business logic in the controller, and have a separate business layer that is not aware of the view technology.

Here are fundamental characteristics of MVC:

Model: encapsulates all of the business logic. It is not aware of the view technology.

Controller: fetches the information needed from the view, puts it together and calls the appropriate models for processing. It contains no business logic.

View: displays the model that it gets from the controller.

I just thought of a good analogy for the Model. Think of it as the brain. It’s the most important thing. You don’t want to distribute its knowledge into other parts. What if you lose the other part, a finger let’s say, do you want to be dumber as a result? I certainly would not like that.

Martin Fowler, in Patterns of Enterprise Architecture, says that the proper definition for the Controller is “input controller.” He has a good explanation of MVC.

“A request comes in to an input controller, which pulls information off the request. It then forwards the business logic to an appropriate model object. The model object talks to the data source and does everything indicated by the request as well as gather information for the response. When it’s done it returns control to the input controller, which looks at the results and decides which view is needed to display the response. It then passes control, together with the response data, to the view.”

“Ensure that the models are completely separated from the Web presentation,” says Fowler.

How can I test whether I have a good MVC? It is not always easy. Here’s a good test: can I add a different view technology without duplicating any business logic?

The biggest benefit of proper implementation of the MVC pattern is that you have a separate business layer. Because it is seperate, it is easier to test — you don’t need a container to test. It is easier to understand. You don’t have duplication. And you are well prepared to add a different view technology to it without a major effort.

Another great benefit is that your architecture remains simple. Your controllers are simple. The business logic might be complicated, but it is in a separate layer and encapsulated in one place.

It is tempting to put business logic into the controller or the view (we all did it). Stop. Don’t do that. (I should yell here. ) Refactor the architecture if you have to. Putting business logic into the controller makes the application harder to maintain, it makes the business logic almost impossible to test, and it also spreads the business logic into several layers. All smells of a bad design.

The Spring framework gives you a skeleton MVC out of the box. But if you look at it, it only gives you the VC part, without the M. You have to add the M, the business logic yourself. It is very easy just to add it into the controller. I that’s what a lot of people do. Then you really have a VC pattern. Make sure you add the missing M and make sure it sits in a different room than the VC.

You will benefit in a big way if you followed the MVC principles. And no exceptions. You are hurting yourself if you follow an ad-hoc approach — a little logic here, a little there.

If you want to be a good coder, when using the MVC pattern, never break its principles.