Controllers != Business Layer?

Question

So I'm assuming people still use a business layer outside just controller logic? If so where's that grey line drawn and what do you not put in your controller classes that you would in your Business Layer project and vice versa? Seems to me like Controllers rid the need for a business layer in your MVC application totally.

Answer 1

The controller layer is part of the view, in my opinion. What you're calling the business layer I call services (not web services; that's just one deployment choice among many).

The business layer knows about use cases and units of work for accomplishing the objectives of users.

The controller is all about validating, binding, and marshaling requests, determining which service is needed to fulfill the request and passing values to it, unmarshaling the response and routing it to the next appropriate view.

So I agree with the hypothesis posed in your title: controller != service.

The classic pattern that came from Smalltalk is Model-View-Controller, which disagrees with my statement by breaking view and controller into separate tiers.

What I'm describing is what is implemented in Java frameworks for both web and desktop. A change in view technology generally means changing the controller as well.

So if the Smalltalk idiom was model-view-controller, the more modern approach would look like view->controller->service->model/persistence. Model means "domain objects", which are independent of all view technologies.

Answer 2

The line is not "grey". It's stark and absolute.

The model (or "business layer") works with any presentation. GUI, command-line, web. And it doesn't require any changes to be wrapped with a GUI (view+control) a Command-line application or a web application.

You know you've done the model ("business layer") correctly when there are no presentation or control features in at all. Further, it's so complete that any GUI can use it directly.