WCF N层架构

Question

I'm working on a fairly straight forward multi-tier application (WPF, WCF, EF 4, and SQL). As far as architecture is concerned, we were planning to include a single "Common" project which will include both entities as well as service contracts.

Are there any advantages/disadvantages to having entities and service contracts in separate assemblies? Or is it usually good to keep them together?

I'm interested in hearing the opinion of others.

Thanks!

Answer 1

Having Contracts in a separate assembly gives you the advantage of the ability injecting to a different entities in a different assembly by providing the Contracts assembly to a developer , and he would implement it and give you a dll that you can put inside the project folder and inject to it using IoC framework like StructureMap without rebuilding,

having the contracts in the same assembly that contains the entities tie the contracts to the implementations...

Answer 2

If you are using a RESTful architecture with other .NET platform consumers - it's helpful to have the Service Contracts in a separate assembly (Shared) so that you can easily share your operation and data contracts with RESTful consumers without exposing any unnecessary data access components to your clients.

I would recommend that you keep the data access and service contracts isolated for this reason.

Answer 3

That is exactly how I structured the design for an e-commerce n-tier app I designed.

There are two common libraries - one for DTO's and another for interfaces.

Then the client and server included those librarues, and the service proxies were generated using common types.

The main advantage here is ease of compilation - you don't have to recreate the proxies when you change the insterface, the client and server are updated automatically.

I also had a utilities app that contained all the helper type stuff I needed.

EDIT: Sorry, just re-read your question. In my case, I had multiple interface libraries - one for the workflow library (with composed interfaces), and another for services (the thing being composed into workflow operations)

So in my case it made sense to keep them seperate.

If you only have one set of interfaces, and those interfaces all make use of your DTO's, there is no reason to seperate them into two libraries - one would be sufficient. Consider though if you may need to share your DTO's between more interface libraries in future, in that case rather keep the DTO's seperate from the interfaces from the start.