0

When I search the internet, I found that some people say that the logic should go in the ViewModel and some people say it should be go in Controller in asp.net with mvc applications.

So I cannot come to a conclusion.

  1. What is the official (the creator's of asp.net with MVC) recommendation for this?
  2. What are the reasons to decide it? (with explanations and examples) ?
Haritha
  • 1,498
  • 1
  • 13
  • 35

2 Answers2

0

I cannot currently provide a source or reference (as per your requirement), but business logic should go in the Controller's action methods, or in another layer called by the action methods (such as a back-end webservice, if your ASP.NET MVC application is only serving as a frontend for an existing application, like what OWA is to Exchange Server).

Central to this justification is the concept of "concerns", in this case a ViewModel object should be only concerned with the transportation and validation (but not verification) of data between the View and the Controller('s Actions). In ASP.NET MVC a ViewModel class should be a POCO (Plain Old CLR Object) consisting of just Properties that correspond to user-supplied data in your Views. In my own projects I extend this to include converting data from Business Entities to ViewModel objects rather than populating the properties directly in the Controller's Actions, I also perform my own validation logic using a modification I made to MVC's pipeline.

Dai
  • 141,631
  • 28
  • 261
  • 374
  • I saw in the internet that one con of implementing business logic in the controller is that `it is difficult to be tested`. – Haritha Mar 27 '13 at 08:32
  • No, that's the complete opposite of reality. If you ensure your business logic is logically separated from presentation because it's in the controller, then you make it a lot easier to test because you can have it render to a mock view or feed it with a mock data source. And you can test your views by supplying a mock controller. – Dai Mar 27 '13 at 08:33
0

View models should only contain logic relevant to presentation. Definitely no business logic.

Business logic shouldn't really go in controllers either. Controllers should be coordinators of the components that are recruited in responding to requests.

For all but the most trivial of applications, you aught to create a services layer that implements business logic and manipulates/persists models.

For larger applications you might also have a dedicated business domain layer accessed by the service layer.

I have a library that I've found useful for implementing and co-locating the domain/rules/workflow in MVC (and other) applications. It's here.

manadart
  • 1,750
  • 11
  • 13
  • Let's say we only have one layer (no service layer). Then where do we put business logic? – Haritha Mar 27 '13 at 10:14
  • 1
    I'm not sure why you would adopt such a constraint. Even if you don't *call* it a layer, you will likely need some separation of business logic from controllers to avoid duplicating code. The most trivial example would be a static utility class with methods that operated on models, but this is also not really to be encouraged in OO design because it's a concrete dependency. – manadart Mar 27 '13 at 10:19