I'm working on a new project and have been pondering about the structure of my application.
Specifications:
There's a myriad of questions on SO dealing with these (or related) issues. Picking up bits and pieces here and there I've come to this:
A few additional ponderings:
All entities sit in the DAL and are only known to the BLL. Presentation does not need to know the entities, because of the DTO's returned by the servicelayer. Since Presentation uses MVVM, DTO's do need to be converted to a ViewModel though.
Am I correct in stating that entities don't need to be a in shared assembly referenced by Presentation as well as BLL? This is the case in an older project of mine with neither WCF or WPF involved. Entities were in a shared assembly and BLL returned these entities which were directly databound to controls in Presentation. This time though, using a servicelayer warrants using DTO's for transport, thus clients don't need to know the entities anymore, just the DTO's.
Additional pondering: who's responsible for creating the DTO's? It's just a mode of transport, so I'd guess the servicelayer.
Conrete question: is this a good approach? Because it feels a bit like overengineering things, I'm already mapping my database model to entities, those entities to DTO's and those to ViewModels, and that feels like it's a lot of overhead.
Interestingly enough, the question right next to this one in the "active" group of the "architecture"'s tag is .NET N-Tier Architecture: What do I do about the Model objects? and it seems to have had a lot more attention than this one, in spite of being very similar.
Anyway, not specifically regarding .Net/WCF/WPF, it all depends on the kind of flexibility you are aiming for (or your requirements mandate). To me, there's nothing wrong with what you're doing and is, overall and IMHO, the smartest approach as it frees you from the rigidness of the data store.
Remember that if you're allowing external systems to connect to yours (via a web API, for instance), you should absolutely not expose your DAL. Even the BLL should be wrapped in a thin layer so that the you can abstract specific needs of the transport layer (which is what WCF tries to achieve but may not be enough if you have special business logic over a specific transport channel - API keys, etc.).
The greatest gain is the ability to customize your DTOs depending on the services being invoked. Just as an example, look at LinkedIn's web APIs. They allow clients to "request" the data that it wants at any given time and build a particular view of the data set, adapted to its needs, decreasing bandwidth usage (for every API service the client does not receive the whole data set, just a particular view that it requests). This is a web example but the design pattern could also apply to fat clients.
Regarding performance, there will surely be an impact in converting entities to DTOs to View objects to etc. But check if your system's performance is not bound by other factors first (database, memory, threading, etc.). The DTO option might even be faster, depending on how you build your services, since you might be sending a lot less information through the network. It's probably more important to design your BLL carefully so that you take the entity to DTO to entity conversation into consideration. The same applies to every other layer in your system (services to presentation, etc.).