MVC: Where to put business logic? [closed]

Answer 1

I would also prefer to keep models clean. The MVC controllers should be used only to make calls and should also be kept clean. So depending upon its reusability, sensitivity and relevance the business logic can be written in

1.WebApi Controller: The advantage of using a webapi controller is that you can expose these as services later to other devices making your code reuseable.

2. BAL / Common commonent: There are some logics which have specific usage and cannot be exposed as an api, can be pushed in this class.

3. Repository: All the database related queries are added in a repository. There can be a generic repository which will implement all the functions (CRUD operations)or specific repositories for each table. Depending upon the operations to be performed.

Answer 2

My team when moved to mvc from webforms (asp.net) did alot of research and came up with the following structure. According to me its not about how big or small the application is. Its about keeping the code clean and clear.

DALProject

AccountsDAL.cs --- > Calls SP or any ORM if ur using any

BLLProject

AccountsBLL.cs ---> Calls DAL

WebProject

Model
    AccountsModel --- > Contains properties And call BLL
Controllers
    IndexController ---> Calls Models and returns View
Views
    Index

Controllers should be responsible for the data passing between model and view. Other than that it there should not be any unnecessary code. For example if you are logging it should be done at model level rather than controller.

Answer 3

There seems to be some confusion around this topic. Mostly it seems that people tend to confuse the MVC pattern with N-tier architecture as an either/or situation. The reality is that the two approaches can be used together, but one is not dependent on the other and neither is required.

N-tier architecture is concerned with separating an application into multiple tiers. A simple example is where the application is split into a presentation layer, a business logic layer, and a data access layer.

MVC is a design pattern dealing with the presentation layer of an application. It is entirely possible to design an application following an MVC approach without separating business logic and data access logic from the presentation layer and thus end up with a single tier design.

The result, if you are following an MVC approach without also separating the application into tiers is that you end up with Models, Views, and Controllers that have bits of business rules and data access logic mixed in with the rest of the logic.

By definition, in an N-tier architecture, the presentation tier is only supposed to be able to communicate with the business logic layer so it should hold that any of the MVC components can only communicate with the business logic layer.

If you are building an application that does not involve presentation, and thus not a presentation layer, you should not have to concern yourself with the MVC pattern. However, you very well may still split your application into multiple tiers and thus follow an N-tier design even though there is no presentation layer involved.

Answer 4

I prefer to put domain logic in the model for a couple of reasons.

1. The model should have no UI code in it and thus be easier to test. Whenever possible, I like to have a fully working (meaning complete test coverage) model before writing any UI code. The controller can trust that the model is doing the right thing and just deal with UI concerns.

2. If you put domain logic in a controller, it's not as easy to share between different apps, or even between different controllers.

Answer 5

I like to keep my models clean as well (ref: @Mark Walsh). The problem of not being able to reuse logic embedded in controllers can easily be overcome through dependency injection, or, if you think there would be too much of that, expose your business/domain logic through interfaces and use the façade pattern in the controllers. That way you get the functionality you need, but keep both the controllers and model nice and clean.

Answer 6

The business logic should not go in your Models Views or Controllers. There should be a separate Business Logic Layer ; the sole purpose of this layer is to handle your business logic. This is more in-line with SOLID.

If you were to put your business logic in M V or C, you end up with code that is difficult to test / reuse.

What about putting the logic in the Models?

That is a bad solution.

You will end up in a Dependency Hell where objects rely on objects.

Even if you have a dead simple function, you'll still have to satisfy all the dependencies to call it.

It will also cause unnecessary and unused data to be passed around for no reason. This could also affect performance depending on how bad it gets.

I should also mention that unit testing becomes a pain in the a** because you have to mock multiple objects just to test a simple function.

Principles of Clean Code Applicable

1. Classes / Functions take only what they need to get the job done.
2. Functions should take 3 parameters or less if possible
3. Name classes / functions / variables intelligently (follow Microsoft's standards)
4. Do not couple business logic to Model View or Controller

Controllers

In your controller, you should be able to use dependency injection to inject the business logic layer. Make sure you controller is only used to route information to the business logic layer. The controller should NOT have business logic directly in it. Any validation needs to be handled by IValidatable on the Model. Any business logic needs to be routed to a separate layer.