Where does business logic go into MVC?

Question

I am new to ASP.Net MVC. After reading a lot of guides and revising my concepts, I have yet to see an approach that clearly demonstrates where the business logic goes.

My application will use a lot using jQuery AJAX (which will trigger Controller actions for various purposes, such as dependent interaction, validation). I will definitely use the ViewModel concept, but I still don't understand where the business logic should be. I do not want to enter a controller or model. Should I put it in a separate service layer?

Answer 1

I think you have largely answered your own question in a separate project.
Not in controllers and not in models at all.

Edit: Please note that the controller is strongly connected with httpcontext, so it is very important to move the logic level to another dll layer.

Answer 2

M in MVC is all that is used to extract and process the information that you use in your application. Therefore, the business level is part of it.

I would just start by creating a separate class library and put all my logic into it. As long as your classes are quite small and clear of responsibility , it is quite easy to reorganize later if you need a separate web service (another project needs access to data).

I usually create a third-class library and make all the definitions (service interfaces and domain models) into it. By doing this, you will follow the split interface template and make it easier to replace the implementation later (and check your business layer)

Answer 3

You can simply put some business process logic in a separate C # class and reference it in controllers. This is how code was isolated during the days of the web form.

Answer 4

The simplest examples I've seen put simple business logic in the controller, but ideally you can create a business layer.

A good example of splitting business logic using MVC3 can be seen in the Microsoft Silk project, which you can download here . In this solution, business logic is allocated to a different project than the MVC project.

In this project, you can see that the controller logic simply handles the relationship between views and view models (note models, not business-level models). Presentation models simply contain information that will be passed on to the views, so if the field in the view changes, the field in the view model changes. The project also goes further to divide presentation models into presentation models for transferring data in representations and form models for transferring data backward, but this is a matter of choice.

This project uses a script transaction template for its business logic. The controller transfers information to the business layer using its own presentation models, which implement the interface in the design of command templates. Information obtained from the business level is carried out through business models of business models. I would strongly recommend that you take a look at this project in order to better understand how separation is achieved.

For further reading of business layers, I also recommend that you take a look at Wrox Enterprise.NET , where several chapters provide a good discussion of business level structuring options, the first of which is the transaction template used in the Silk project.

Hope this helps.

Answer 5

Business logic in theory involves a mid-tier three-tier architecture.