WCF DataContracts and underlying data structures

Question

I am wondering what makes sense in relation to what objects to expose through a WCF service - should I add WCF Serialization specifications to my business entities or should I implement a converter that maps my business entities to the DataContracts that I want to expose through my WCF service?

Right now I have entities on different levels: DataAccess, Business and Contract. I have converters in place that can map entities from DataAccess to Business and from Business to Contract and vice versa. Implementing and Maintaining those is time consuming and pretty tedious. What are best practices in relation to this?

If I were using an OR/M such as NHibernate or Entity Framework should I be exposing the entities from the ORM directly or should I abstract them the same way I am doing now?

Unmannerly

Answer 1

In general, I think from a best practices standpoint, you should not expose the structure of your business objects as data contracts, but rather define "data contract-specific" classes and convert Business to Contract. It may require extra work, but from a separation of concerns and protection from change standpoint the extra work is probably worth it.

The Microsoft patterns & practices "Service Factory Modeling Edition" implements this, and also provides tooling to auto-generate Business <=> Contract converter classes -- it's an excellent VS add-in, and also represents Microsoft's best practices for WCF.

Leukorrhea

Answer 2

I typically don't expose my business/data entities across the wire since I like to adhere to the single responsibility principle (srp). To explain, the data entities were created to map to the underlying relational (db) model. So the only reason they should "change", is because of a change to the relational model, that's it.

The moment you expose such entities so they can cross the wire, then they're serving two purposes. It may seem like overkill, but it keeps things cleaner and transparent...which yields for a simpler design.

Developer

Answer 3

Just to add to the above answers: The object that the webservice exposes is called the Data Transfer Object (DTO). Having a DTO to map your Business Entity object (BEO) is good because of the separation it provides between your webservice and the actual implementation/logic that lies behind the web-service.

Finally, here is how you can decorate the DTO so that when it is exposed by the WSDL the names reflect the actual objects it represent (instead of objectNameDTO or something ugly like that).

//Business Entity
class Person
{
   public string Name{ get; set; }
   public int Age{ get; set; }
}


//Data transfer object
[DataContract(Name="Person")] //<-- this is what makes the WSDL look nice and clean
class PersonDTO
{
   [DataMember(Name = "Name", Order = 0)]
   public string Name{ get; set; }
   [DataMember(Name = "Age", Order = 1)]
   public int Age{ get; set; }
}

Masterson

Answer 4

Something to also consider, I agree with the separation but it usually winds up leading to "Translators" or some such code to copy the data from the DTO to the Business Entity. This is where a library like AutoMapper (http://automapper.org/) comes in REAL handy and does away with the need to write the translation layer.

Aegis