2

I'm building a prototype web application using ASP.NET MVC 5. Part of the application is the display of a grid of records, each of which has a button action to 'Archive' that record. Another page displays the archived records. A WCF service provides the Model and persistence.

I have built a controller for each of the pages and in each controller I retrieve all of the records and then select either the current or archived records and display only those. There is an additional method on the current records Controller to set the Archive status of the record and then redisplay the current records.

I suspect that this is a potentially poor design as business decisions are being made in the Controllers and not the Model. Should I instead create a Model 'layer' in the MVC application with methods that return either current or archived records as required, or update the status of records, thus 'wrapping' the WCF Service, or is this adding a layer of complexity where it is not necessary?

What is the pure decision to be made based on the MVC concept? Should any business decision (even one as simple as filtering records based on status) be made in the Model and not the Controller?

  • Presentation logic should reside in the presentation layer (the MVC project itself). Application logic should reside in the application layer (application services). Business logic should reside in the domain model (domain layer). See Vaughn Vernon's sample application. It's in Java, but it's still valuable. – Songo Oct 15 '14 at 14:17

2 Answers2

2

I don't use ASP.Net, but when it comes to MVC, I like to keep all layers clearly separated.

It is better to separate the domain model from the persistence layer, so that you can easily provide another one if needed. The domain model should contain in my view only basic properties and methods. Methods that involves processing, even the simplest ones, should be implemented in business objects. The controller is somehow related to the MVC framework, and, on the other hand, you want your service layer to be independent of it.

That being said, in your case, the filtering, if it doesn't involve any additional processing, could also sit in the persistence layer.

The method setArchiveStatus could sit in the model, if, again, doesn't involve further processing and it is only a domain model property.

Adrian Ber
  • 149
0

Generally you want thin controllers that handle request in a RESTful way, with any business logic in the models.

I would put any state related stuff such as logged in user and any request related stuff such as 'records for this user' in the controller.
I would put the database calls that are specific to current or archived records as methods in the model and then call those methods from the controller.

Michael Durrant
  • 13,199