MVC + WCF: Architecture Design Decisions

Question

I'm currently working on a project that consists of an ASP.NET MVC web application with a back-end wrapped in WCF services. I've used MVC and WCF on past projects but I've never been responsible for designing the architecture from scratch. I'm hoping for some feedback on my current design to make sure that I'm employing good design practices from a high level architectural view.

Here is the dependency diagram to give an idea of how things are structured:

A few things to note:

• Common MyApp.Utilities project is for any functionality which needs to be shared across layers. Currently it only contains extension methods.
• Service contracts and data contracts are in a common project which is shared between both layers.
• EntityFramework is being used for data access.
• Mapping goes Entity <=> DTO (data contract) <=> ViewModel
  • Still working on this, using AutoMapper and not entirely sure as to how I should "rehydrate" the DTOs when they are passed back from the presentation layer.
• ServiceImplementation is simply a wrapper for business logic which is contained in a separate assembly.
• The presentation and service layers are to be deployed to separate physical servers
• Packages are all contained in a single folder in the solution's root folder and are checked into version control

Does any of this stand out as bad practice?

Answer 1

The architecture that you proposed above is pretty similar that I've used in my projects. Some comments:

• Data contracts (Entity Framework) are not in a common project;
• We are using currently AutoMapper to map between entity framework model and service model (simple and complex types) and between service model and view model.
• We have interfaces implementation in DAC, Service layer and Presentation layers, to use dependency injection (we use Ninject), to make layers more "testable", so we also have contracts in all these layers.
• Presentation is basically Web Api with restful methods.

It works great and I don't see any issues in your archtecture.

Answer 2

• Service contracts and data contracts are in a common project which is shared between both layers.

I would avoid this. It may seem like extra work but I would break these out into separate namespaces and classes, even if it leads to duplication. I normally shy away from planning for the unforeseen, however, I have never had a project in which all my data contracts aligned with all my service contracts. The hacks to accommodate the differences tend to lead to confusing anti-patterns.

The majority of these classes will have identical properties and they can easily be mapped using an auto mapper.