Question

Is it good practice to reference my web applications domain layer class library to WCF service application.

Doing that gives me easy access to the already existing classes on my domain model so that I will not need to re-define similar classes to be used by the WCF service

On the other hand, I don’t like the coupling that it creates between the application and service and i am curious if it could create difficulties for me on the long run.

I also think having dedicated classes for my WCF app would be more efficient since those classes will only contain the members that will be used by the service and nothing else. If I use the classes from my domain layer there will be many fields in the classes that will not be used by the service and it will cause unnecessary data transfer.

I will appreciate if you can give me your thoughts from your experience

Answer 1

I personally frown on directly passing domain objects directly through WCF. As Krzysztof said, it’s about a data contract not a contract about the behavior of the the thing you are passing over the wire.

I typically do this:

• Define the data contracts in their own assembly
• The service has a reference to both the data contracts assembly and the business entity assemblies.
• Create extension methods in the service namespace that map the entities to their corresponding data contracts and vice versa.

Putting the conceptual purity of what a “Data Contract” is aside, If you begin to pass entities around you are setting up your shared entity to pulled in different design directions by each side of the WCF boundary. Inevitably you’ll end up with behaviors that only belong to one side, or even worse – have to expose methods that conceptually do the same thing but in a different way for each side of the WCF boundary. It can potentially get very messy over the long term.