Controllers! = Business Layer?

So, I assume that people still use the business layer outside the controller logic? If so, where is this gray line drawn and what do you not put in your controller classes that would be in your Business Layer project and vice versa? It seems to me that controllers completely eliminate the need for a business layer in your MVC application.

+4
source share
3 answers

The controller layer is part of the view, in my opinion. What you call the business layer, I invoke services (and not web services, which is just one deployment choice among many).

The business layer is aware of use cases and units of work to achieve user goals.

The controller is designed to check, bind and marshal requests, determine which service is needed to fulfill the request and pass values ​​to it, untie the response and route it to the next appropriate view.

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

The classic template that comes from Smalltalk is the Model-View-Controller, which is not consistent with my statement, breaking the view and controller into separate levels.

What I am describing is what is implemented in Java infrastructures for both the Internet and the desktop. Vision change technology usually means changing the controller.

So, if the Smalltalk idiom was a model-view controller, a more modern approach would look like view-> controller-> service-> model / persistence. A model means “domain objects” that are independent of all viewing technologies.

+9
source

The line is not gray. It is absolute and absolute.

A model (or "business layer") works with any presentation. GUI, command line, network. And it does not require any changes that need to be wrapped in a graphical interface (view + control), a command-line application or a web application.

You know that you made the model (the "business layer") correctly when there are no presentation or management functions at all. In addition, it is so complete that any GUI can use it directly.

+8
source

Simply put:

  • The controller must contain application-specific logic.
  • The "business layer" must contain the business logic.

In accordance with the approach of Eric Evans under the control of the domain "Business Level" contains:

  • Service Level: The interface is designed around a use case.
  • Domain models: objects of the main area, objects, value objects, etc.
  • Data Access Objects: Repositories

Also note that domain models are not a data access layer. It can encapsulate data access, but not the data access level itself.

+3
source

Source: https://habr.com/ru/post/1301935/


All Articles