CODEWITHSUNDEEP
asp.netasp.net-mvc
PositiveGuy
PositiveGuy

Reputation: 47783

Controllers != Business Layer?

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.

Upvotes: 4

Views: 575

Answers (3)

S.Lott
S.Lott

Reputation: 392010

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.

Upvotes: 8

duffymo
duffymo

Reputation: 308998

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.

Upvotes: 9

ronaldwidha
ronaldwidha

Reputation: 1345

To put it simply:

  • Controller should contain the application specific logic.
  • "Business Layer" should contain the business logic.

Following Eric Evans' Domain Driven Approach, the "Business Layer" contains:

  • Service tier: the interface is designed around the use case scenario
  • Domain Models: the core domain objects, entities, value objects and more.
  • Data Access objects: repositories

Also note that the Domain models is not the Data Access tier. It might encapsulate data access, but is not the data access tier itself.

Upvotes: 3

Related Questions