Should there be a Service Layer in Asp.net mvc?

If you follow Domain Driven Design to the letter, you'll find that there are 3 types of service (don't you love overloaded terms?).

• Domain Services : Encapsulates business logic that doesn't naturally fit within a domain object, and are NOT typical CRUD operations - those would belong to a Repository.
• Application Services : Used by external consumers to talk to your system (think Web Services). If consumers need access to CRUD operations, they would be exposed here (but handled by the appropriate Repository)
• Infrastructure Services : Used to abstract technical concerns (e.g. MSMQ, email provider, etc)

Sounds like you need Domain Services to encapsulate/share your business logic.

Hope that helps!

TBH, I've gone both ways on this. My current perspective is that a Repository is a service, it's just a service which happens to have the job of handling CRUD ops for a domain aggregate root. now, if you're "repositories" are directly mapped 1:1 with your entities (and therefore, not repositories so much as DAOs') then I could see the argument. But generally, I add layers of abstraction as needed, but not until proven that they're needed for a given app. Otherwise, you over-engineer.

I like the extra level of abstraction a service layer provides between my controllers and repositories. I feel it helps tremendously in fulfilling the Single Responsibility Principle.