ASP.NET MVC: What goes where?

Question

I am about to start developing a medium sized ASP.Net MVC application. I am trying to get the design right. I intend to have the following layers:

• UI layer (MVC)
• Service Layer
• Repository Layer
• Data Access Layer

I will be using Unity as my IOC container and EF4.1 Code First for Data Access.

The app will be split into several assemblies. I have a problem deciding which assemblies I will need and where to put the following:

• Entities/Domain objects e.g. Customer, Invoice
• DTOs e.g. CustomerDTO, InvoiceDTO
• Service interfaces e.g. ICustomerService
• Repository Interfaces e.g. ICustomerRepository
• Services(Service interface implementation classes) e.g. CustomerService
• Repositories (Repository Service implementation classes) e.g. CustomerRepository
• ViewModels e.g. CustomerViewModel
• Enums

My question is: How do you usually split yours and why?

Edit: prompted by the @TheHurt's answer.

How would the references be between the assemblies, i.e. which assembly would be referencing which?

Answer 1

This is how I might tackle it:

App.UI assembly:

• ViewModels go in Models area.

App.Repository assembly:

• Abstract implementation of concrete repository.
• ICustomerRepository

App.Repository.SQL:

• Concrete implementation.
• EFCF POCOs

App.Services assembly:

• Abstract service.
• ICustomerService
• DTOs

App.Services.Implementation:

• Concrete service.
• CustomerService

App.Common:

• Shared code.
• Enums

There are a couple issues that I still struggle with. You lose the data annotations from EFCF when you cross the services boundary. So then you have to do server side validation or you have to keep your view models validation in sync with the repository entities. It feels that the more layered things are, the more DRY is violated. I suppose that is par for the course though when your view models don't map to your entities directly. You could have your view models be your DTOs and toss them into the Common assembly, but that seems to couple things too tightly if you have the need to be super flexible with your services.

EDIT

If you are wanting to integrate WCF into the mix you would probably want to create data contracts that are very close to the MVC view model (or use the contracts as the view model). You probably wouldn't expose that to the world as the service would be specific to that implementation of your MVC site, spin up another service for public consumption. If you are doing a WCF service you probably want to have all of your business logic in the service, the controllers would just handle navigation logic.

Side note, I try to stay away from the "metal" as much as possible, while developing a design that will allow me to separate the code into various layers in the future. If I cannot clearly explain the various system layers to my manager with one sheet of paper, the design is more than likely too complex. Everything for the most part will look pretty in Visio if it is designed well.

As far as how things reference each other: UI would ref the Serivce (or service implementation, which may not be needed. Just keep it all in the same place.). Service refs the Repository. The repository implementation refs nothing, since it is loaded by IOC. Everything refs Common.