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

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

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:
I believe that the approach in the link above is outdated and should not
be used in favor of DataAnnotations (and overriding 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?
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?
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?