Where does the business logic go in MVC?

Question

I am a beginner to the ASP.Net MVC. After reading many tutorials and digesting its concepts, I have yet to see an approach that clearly demonstrates where does the business logic go.

My app will have a lot of use of jQuery AJAX usage (which will be calling Controller's Actions for various purposes such as dependent interaction, validation). I will definitely use the ViewModel concept, but I am still unclear where the business logic should reside. I do not want to put in the controller or a model. Should I put it in a separate service layer?

Answer 1

I think you pretty much answered your own question, in a separate project.
Not in the controllers and absolutely not in the models.

Edit: Notice that the controller is highly coupled with the httpcontext so it will be a very smart thing to move the logic layer to a different dll-layer.

Answer 2

The M in MVC is everything that are used to fetch and process the information that you use in your application. The business layer is therefore a part of it.

I would just start by creating a separate class library and put all of my logic in it. As long as your classes are fairly small and has a clear responsibility it's quite easy to refactor later if you need a separate webservice (another project needs access to the data).

I usually create a third class library and put all definitions in it (service interfaces and the domain models). by doing so you'll follow the separated interface pattern and make it even easy to swap the implementation later on (and to test your business layer)

Answer 3

Business logic in theory engaged the middle tier of a 3-tier architecture.

Answer 4

You could simply put some of the busines logic in a separate c# class and reference it in the controllers. This is how code was isolated during the web form days.

Answer 5

Most simple examples i've seen put simple business logic in the controller but ideally you may want to create a business layer.

A good example of seperating out the business logic using MVC3 can be seen in Microsofts project Silk which you can download here. In this solution the business logic is separated out into a different project that that of the MVC project.

In this project you can see that the controller logic simply handles communication between the views and the view models (note view models and not business layer models). The view models simply contain the information that will be passed to the views, therefore if a field on the view changes, the field in the view model changes also. The project also goes further to seperate out the view models into view models for passing data into the views, and form models for passing data back but this is a matter of choice.

This project uses the transaction script design pattern for its business logic. The controller passes information to the business layer using its own view models which implement an interface in a command pattern design. Information passed back from the business layer is done so via the business layers own business models. I would thoroughly recommend that you take a look at this project to get a better understanding of how the separation is achieved.

For further reading of business layers I would also recommend you take a look at Wrox Enterprise .NET where a few of the chapters provide a good discussion of the options for structuring the business layer, the first of which is the Transaction Pattern used in project Silk.

Hope this helps.