1
votes

(I am a very beginner in MVC)

I mean to have a business logic layer with the domain models and an application service layer with view models and controllers obtaining view models only from application service methods. Controllers doesn't contain any logic and the MVC models are the view models (from the app service layer) which contains logic only related to displaying.

Any tutorial I have seen on ASP.NET MVC focuses on having logic in controller classes, but I think in this way (in a large app) you can duplicate business logic, writing redundant code.

2

2 Answers

0
votes

Is it a good approach to make a difference between domain models and MVC models

Definitely, I always separate my domain models from my view models because, like you, I agree that domain models don't belong in the controllers.

Controllers in an ASP.NET MVC project are effectively view controllers and as such shouldn't really contain business logic. Using a service layer is generally the best way to manage communication between your presentation / business layers (like you appear to be doing anyway).

0
votes

Yep, its a good idea to keep them separate. The way I've seen it done is that you have your "Business Objects" namespace, then your 'View Models' namespace. The objects in the 'View Models' namespace are the Models for MVC and usually contain a mix of regular types and instances of business objects.