Refactoring fat controllers and handling validation and logging in the service layer

Question

I currently have an application which suffers from Fat Controllers. I am trying to pull out the business logic into a service layer and am hoping to clarify my approach.

For raising Model errors I had planned on using an approach like described here: http://www.asp.net/mvc/tutorials/older-versions/models-%28data%29/validating-with-a-service-layer-cs - about 1/2 of the way down using the IValidationDictionary approach.

But I see this approach is not discussed in newer versions of the documentation. The validation in the service layer section is completely removed in the newer versions.

I hope that is enough context for the following questions / validation of my approach:

1. I believe that the approach in the link above is outdated and should not be used in favor of DataAnnotations (and possibly overriding IsValid - this may be naive, I don't fully understand the workflow of validating the ModelState.IsValid yet). Am I understanding correctly or are these somewhat separate concerns?
2. I would expect to have a mix of strongly typed views to both Entities (on simple forms that have a 1-1 mapping of fields to the entity) and DTO's (on forms with a less simple mapping to entities). Is it possible to have the entity validations bubble up to the DTO's to avoid duplicating non-business requirement validations? On entity's which could be strongly typed without a DTO should I be including business logic validations on the entity (this seems wrong)? Am I even thinking about/approaching this correctly?
3. The site is using a repository approach - can I skip the service layer and have my business logic spread across data annotations and the repository? Again am I asking the right question?

Answer 1

1. DataAnnotations are the current (MVC 4) best practice approach to model validation. In terms of the workflow of model validation, validation happens at the time of model binding which is when the MVC Framework examines values from the request and attempts to bind/hydrate/populate the parameters listed in the action method being targeted by the request.

2. When using a service layer with MVC it would be very natural and convenient to merge your DTOs with what are called View Models in MVC. The purpose of both is to only encapsulate the data that will be passed between two points. So I would say create one class to use as the DTO and View Model and tag its properties with the DataAnnotations for model validation.

3. This question is a little more subjective and also depends on the intended network architecture of the deployed application. A service/application layer would be inherent and necessary if you are targeting a 3-tier deployment architecture with a web, app and database server. That being said, if the network architecture is not set than there may be no real reason to have a service layer, particularly if there will be no need for other applications, either internal or external, to consume the logic contained in the service layer. It is perfectly fine to implement your business logic within the model validation and repository.