ASP.NET MVC: What is happening?

Question

I'm going to start developing a medium-sized ASP.Net application. I am trying to get the design right. I intend to have the following layers:

• User Interface Level (MVC)
• Service level
• Repository level
• Data access level

I use Unity as my IOC container and the first EF4.1 code to access data.

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

• Objects / Domain objects, for example. Customer Invoice
• DTO, for example. CustomerDTO, InvoiceDTO
• Service interfaces, for example. ICustomerService
• Repository interfaces, for example. ICustomerRepository
• Services (service interface implementation classes), for example. CustomerService
• Repositories (repository service implementation classes), for example. CustomerRepository
• ViewModels, for example. CustomerViewModel
• Transfers

My question is: How do you usually share and why?

Edit: response to @TheHurt.

How will there be links between assemblies, that is, which assembly will link to which?

Answer 1

Here is how I can handle this:

App.UI assembly:

• ViewModels go to the "Models" area.

App.Repository assembly:

• Abstract implementation of a specific repository.
• ICustomerRepository

App.Repository.SQL:

• Specific implementation.
• POCOs EFCF

App.Services assembly:

• Abstract service.
• ICustomerService
• Dtos

App.Services.Implementation:

• Specific service.
• CustomerService

App.Common:

• Common code.
• Transfers

There are a couple of issues that I still face. You lose data annotations from the EFCF when crossing the service boundary. Thus, you need to perform server-side validation, or you must synchronize the validation of view models with repository objects. It is felt that the more layered things, the more DRY is broken. I believe this is appropriate for the course, though when your view models are not directly mapped to your objects. You could have your view models be your DTO and throw them into the general assembly, but that seems to be too much of a match if you need to be super flexible in your services.

EDIT

If you want to integrate WCF into the mix, you probably want to create data contracts that are very close to the MVC view model (or use contracts as a view model). You probably could not expose this in the world, since the service will be specific to this implementation of your MVC site, deploy another service for public consumption. If you are running a WCF service, you probably want to have all your business logic in the service, the controllers will simply handle the navigation logic.

Notice, I try to stay away from the "metal" as much as possible, developing a design that will allow me to split the code into different layers in the future. If I cannot clearly explain the various system levels to my single-sheet manager, the design is more than likely too complex. Everything for the most part will look beautiful in Visio if it is well designed.

As for how things refer to each other: the user interface will refer to Serivce (or to an implementation of a service that might not be needed). Just keep everything in one place. The service refinances the repository. The storage implementation does not return anything because it is loaded by the IOC. All links are General.