ASP.NET MVC: Putting application logic in models

This may sound like a stupid or unconstructive question but I'm a fan of not creating so many layers to reduce the amount of code that has to be written and maintained. In a classic scenario, the application logic would be in one class which calls the business layer. H开发者_Python百科owever, if the application logic is simple enough, would it be a crime if I were to put application logic in view models? In my case, this would entail calling the business layer in my view models.

yes, it would be a crime and completely destroy the mvc nature of... mvc.

if you have to, put application logic in your controller.

Surely it is not a crime. But it is good to understand why the Application Logic is "Normally" (what is normal) separated from the User Interface layer. The most important reason that is usually given for this separation is the ability to re-use the application logic when you application gets another User Interface implementation. This can be another technology, or another deployment model. Also for maintenance and readability this is often a best practice.

The fact that you are talking about a viewmodel probably means that you are creating a controller class that has no dependency on the view, according to MVC. This is already a separation in some sense from your user interface.

So my opinion: If you have the need / requirement / wish to modernize your user interface in the future or have multiple user interfaces target the same application logic, put some effort in a separate application logic component. Otherwise, you are not commiting a crime by implementing your application logic in your controller.