What are the pros and cons of using WCF Service with DataContracts VS Entity Framework Entities Object?
If i generate Data Contracts using ADO.net Self Tracking Entity Generator the classes in my data layer.
What will the best way of using it in my WCF service? Will the datacontract genrated ADO.net Self Tracking Entity Generator will be exchnaged via the service or WCF service will still use the default Entity framework objects?
Main advantage of STEs (Self tracking entities) is implementation of change set. It means that you can return STE from web service's operation modify entity (or whole entity graph) and call another operation to post updated STE back to web service for processing. EF will automatically detect changes in STE and process them.
This is not possible with Entity Framework entities because it can track changes only if entity is attached to ObjectContext but the entity is detached when returned from web service operation.
Drawback of STEs is that you have to share assembly which defines them among service and all clients. STEs are not for interoperable solutions.
At the moment most projects are developed with third type of entities - POCOs. POCOs are also not able to track changes when detached from ObjectContext. It is the feature of STEs.
It depends on what type of work you are doing.
Using DTOs (Data Transfer Objects) which form your Data Contracts and are separate from the EF model will give you more control over what get serialized or not. This is important for compatibility and versioning with multiple clients.
http://martinfowler.com/eaaCatalog/dataTransferObject.html
Using EF with POCO is probably next in terms of control and separation with the default database generated form last. However these two are easier to use and more flexible when used with Silverlight clients.
