Passing Business Objects from a WCF Operation (service Layer to Data Layer)

Question

I am building a WCF service.

The Data Contract objects will be the exact same as the Business Objects.

Should I create Data Contracts in my WCF service or reference my BO Layer and use those Business Objects in my WCF Operations?

Answer 1

I would split them in different projects:

• Foo.DataContracts
• Foo.BusinessModels
• Foo.Services

Reference BusinessModels and DataContracts in Services. Then map the model classes to contract classes using AutoMapper and vice versa. You can then later change your models without breaking your WCF clients, since they rely on the contracts.

Answer 2

If your business objects can be serialized without muddling the concerns of serialization in with the business logic, then I'd say go for it.

A better alternative though is to bring your business logic layer behind the Services layer and expose simple DTOs from the service that your view can bind to.

I wrote an article on this approach with WCF RIA Services that translates pretty well to standard WCF Web Services

Answer 3

I think in the same line of @valpolushkin though I have not used AutoMapper till now.

See my answer in WCF Message & Data Contract, DTO, domain model, and shared assemblies for an example where the use of Business Entities as Data Contract can cause breaking changes.

I think, it is a very bad practice to use Business Objects as DataContracts. The Service need to be autonomous. The service may be used by clients that has / has not got Lax Versioning.

Refer Service Versioning.

It is easy to mistakenly believe that adding a new member will not break existing clients. If you are unsure that all clients can handle lax versioning, the recommendation is to use the strict versioning guidelines and treat data contracts as immutable.

Also, refer MSDN - Service Layer Guidelines

Design transformation objects that translate between business entities and data contracts.