Questions about common patterns in WCF, in a layerd architecture

We're about to set off our first larger WCF project, and we're having some concerns on how to layer our application correctly and where all the patterns go.

The services will primarily be consumed by applications on the Intranet, and secondly by customers over the Internet.

Our idea was to layer the application this way, inspired by DDD and Microsoft Spain's N Layer App:

• Infrastructure layer
  • Using EF4 (POCO), and the repository pattern
• Domain layer
  • So far we have a few domain services here
• Application layer
  • Nothing here yet
• Distributed services layer (WCF)
  • This is where the questions begin to arise.
• Presentation layer

Now we have been reading lots of material, and as an example, Fowler mentions the Remote Facade pattern and Data Transfer Objects as distribution patterns in his book Patterns of Enterprise Architecture.

If I understood facades and WCF correctly, my remote facades will be the service contracts in WCF. However, Fowler has lots of these facades each of their own class (like Album Service), but in WCF I only have one service contract and one class (Microsoft does it in their N Layer App, calling it IMainModuleService)? We can of course "simulate" multiple facades using partial classes, but I don't feel like thats "the way" if you understand. But is this the way it's done in WCF, or do you ignore the Remote Facade pattern completely?

Fowler suggests that you send DTO's over the wire instead of business entities which sounds reasonable to me. But many samples that I've seen does not do this. Do you do this in WCF?

Assuming that you're using DTO's in WCF, these would be our data contracts, right? Implementing DTO's, Fowler has an example using an Album Service (the facade) which uses an AlbumAssembler class (one pr. DTO?) for assembling the DTO's using the business entities. I imagine that this is done using services from the application-/domain layer?

But where are these DTO's assembled? Is this done in the application layer where some validation occurs aswell, or where does this responsibility lie? I really need some guidance and best practices here wh开发者_运维技巧ich I hope you can give me.

These are some of our questions at the moment which we hope that you can guide us through. Any comments on the overall architecture will also be greatly appreciated. Another question that we haven't considered much yet is best practices on how to handle security in WCF (using WIF?), in enterprise applications. If you have any comments on that matter, please share them.

However, Fowler has lots of these facades each of their own class (like Album Service), but in WCF I only have one service contract and one class

You can define multiple service contracts, all of which define their own service endpoint. Generally one service contract should offer a well defined set of operations, like a class has ideally a limited set of public methods.

Fowler suggests that you send DTO's over the wire instead of business entities which sounds reasonable to me. But many samples that I've seen does not do this. Do you do this in WCF? Assuming that you're using DTO's in WCF, these would be our data contracts, right?

You can decorate your business entities with the Datacontract and Datamember attributes and this way make them DTOs as well. This is a matter of coupling between your business entities and the datacontract. If you want low coupling you define a dedicated DTO and copy its datamember values from the business entities.