MVC: Where to put business logic? [closed]

Answer 1

Generally speaking, business logic shouldn't reside in any of the MVC players; it should only be consumed by your controller actions.

As many have mentioned, it's best to create a library to host business logic as a set of client agnostic, reusable components.

When done this way, we greatly increase reusability, compatibility, scalability, and testability with our software. We also reduce our dependence on certain framework features, which makes it easier to migrate to newer / different technologies.

Abstracting our business logic into a stand alone assembly (or assemblies) has served us well over the years. Our business logic can then be consumed by virtually any .NET technology (ASP.NET MVC/API/Core, WPF, Win Forms, WCF, UWP, WF, Console, etc.).

In addition, we like our middle tier to handle business rule and validation logic to reduce our dependencies on the .NET MVC Framework's. For example, we avoid using the .NET MVCs validation helpers and instead rely on our own. This is another factor that allows us to easily consume our business logic from any .NET technology.

Logically designing our middle tier this way has allowed us to easily achieve this physical architecture:

It was written with Peasy.NET, and has served us well over the years. So well in fact that we decided to open source it.

If anyone is curious as to what our middle tier looks like, here is a sample of a client agnostic, business layer. It also showcases the consumption of it by multiple .NET clients (ASP.NET MVC, Web Api, and WPF).

Hope this helps someone!

Answer 2

I know that it's a question about MVC, but I think the example I'm giving (Web API) will be usefull.

I'm developing my first Web API and I'm re-using the business logic from other applications. To be specific, it comes from an external DLL, so my API is used just to "talk" with a SAP solution, receiving requests from PO and send responses back.

How could I put my logic (already implemented) into my controller? I don't need it. My controller will only receive, validate requests and compose responses to send data back.

I'm working with ViewModel classes and all they must have is a mapping function, just to read information from TransferObjects (that comes from the external DLL) and translate to a ViewModel.

I'm not comfortable with my application (in this case Web API) holding the business logic, I think that the re-usability will be lost in this way.

I'm treating my business logic as a dependency that I inject into controller.

I've done a lot of refactoring in the legacy to provide a Unit Testable solution, I had to create a lot of interfaces and implement some design patterns into the legacy to provide this solution.

In my point of view, the business layer must be apart of the application, preferably in another class library. So you will have a real separation concept implemented in your application.

Of course, if your CORE (business) is your application (API/WebSite), the business rules will be implemented into your MVC classes. But in the future if you want to develop a new app and some business rules are the same, I bet you will have a lot of problems just to maintain the same logic implemented in both applications.

Answer 3

As ahanusa wrote, you should put your business logics into separate DLL or separate directory.
I often use a directory named Logics at same level of Models and Controllers where I put classes which do business logics.
In this way I let both models and controllers clean.

Answer 4

The general answer I have is that business logic normally fits into two categories:

Object Oriented Business Logic: Gets modeled as objects (in the model), usually injected as repositories.

Procedural Business Logic: Goes in a service with an interface that can be injected into a controller.

Controller Logic: Logic that controls how commands are received and passed to the models/services, then how those results are passed to the view.

Controllers should have no business logic, it's a very specific part of a design pattern for controlling how a user interface passes input off to the models that handle business logic (or services if your problems are more procedural in nature).

Answer 5

I like to keep my models clean I.e. Just with properties and no business logic. I always think its good to inject dependencies into the controller and these dependencies contain the logic I perform on my models. I like to adhere to the single responsibility principle where possible and I find that models with tons of methods get bloated very quickly. There's pros and cons for both, injecting a lot of dependencies has an overhead yet allows to test in isolation and keeps classes simple and you'll end up having leaner controllers. Despite my logic not actually existing on my model as members of the class, its still business logic. I tend to not have business logic defined in the controller as mocking things like the Httpcontext are a bit of a nightmare and unnecessary.

Answer 6

The business logic belongs to the problem domain and everything that belongs to the problem domain goes to the model in MVC.

The controller should be responsible for passing the data from the model to the view and from the view back to the model. The controller is therefore the bridge between what the user interacts with and how the program models and stores the state of the problem. The plumbing, so to speak.

The key here is the distinction between the business logic and the plumbing logic. In my opinion, what the autogenerated Account Controller does is mostly plumbing, not really business logic. Keep in mind that the plumbing logic isn't necessarily short at all, so you don't need to impose artificial limits (like "X number of calls at most in the controller").