DataContract vs persistence model - Guidance needed

Hi forum

I really need some architectural guidance on the above subject. Here's the scene and how I chose to implement it so far:

I have layered server, which host WCF services. These are the layers:

- WCF Layer
- Business layer
- Persistence layer

The persistence layer is not the database, but merely a repository of method, which operates on the persistence model.
The persistence model is exposed with a OR mapper (Vanatec OpenAccess) and is highly navigable in respect to associations between persistent classes.
The WCF layer is the transaction boundary, which has the role of calling the right methods (in the right order) in the business layer. So you can say that the WCF service methods controls the steps involved in each "business transaction".

One of my team members are arguing that the persistent model IS the data contract of the WCF services, where I am the opinion it is absolutely not. Here's my arguments:

- The WCF service and data contract must be versionable
In my opinion versioning of the service and data contract has to be done indepently of the persistent classes as the service and data contract for the service might include non-persisted properties. The core at the problem is: You might not want to expose the whole persistent model as a datacontract to the service. When a change in the persistent model occurs, you might not want to expose that change in a datacontract to the service either.

- The data contract for each service is a "view" of a subset of the persistent model + often the result of some "calculated" properties done in the Business layer.

The bottom line is:

The persistent model and the service data contract model are NOT the same. They have different semantics in terms of dynamics. In other words: The service interface is of more dynamic nature than the persistence model. This fact alone (in my opinion) justifies that the "two models" are separated.

However, bringing in two models, also creates the need for mapping between these models. I think it is "worth" the trouble to do that.

Any thoughts, issues, questions, whatever is highly valuable.

Regards

Henrik Gottig

Answer this question

DataContract vs persistence model - Guidance needed

ccote

Henrik,

I would agree with you. Try and separate the two models, particularly if you do envision independent changes within each layer. Another important thing to note is that if you plan on building other applications on the persistance model that does not require WCF, you wouldn't want a WCF polluted persistance layer. I tend to take this sort of purist approach. However, if these two things aren't of a concern in your project (which they seem to be), architecturally I would take the speed advantage of not having a distinction between the two.
smudie

You are completely bypassing the DataContract step if you use IXmlSerializable:

Message->IXmlSerializable.ReadXml()->[map to entities, reference them from IXmlSerializable type(s)]->Operation invoked (passing IXmlSerializable type(s) with reference to entities - do what you want with them now)

On return, WriteXml() is called, you must have access to your entities from there to serialize them.
CodeDjinn
You are absolutely right to separate the service and data contracts from the ORM entities. This could be completely crippling if you ever changed how you did data access on the back end. Not to mention interoperability and that likely those entities are not data contracts anyways.

You also bring up the classic dilemma of "how do I generate the service contract " vs. "what types do I use to represent my business or data entities at runtime ". In a perfect world, if you are building a system from scratch, you define data contracts to represent your business entities and you use those to write to the database using custom, optimized data access code. That removes the need to map from business entities to ORM entities, and in many cases can be better for performance. That also generates your service contract for you with schemas for those data contracts.

This approach does not work well if:
1. you have a set of XSD schema to adhere to in the WSDL contract for interop
2. you already have business entities that are not data contracts and you want to leverage those at the business tier
3. you already have data entities (ORM) at the data tier and you want to leverage those in the business tier as well
I think you are case #3. So, your approach should be to leverage those ORM entities but still create a WSDL contract with schema that define the messages based on what data you really need to pass to and from each operation. If performance is not a concern, you could design data contracts that represent the data you want to see passed for each operation. But, performance is always a concern, so a better way would be to use an IXmlSerializable type, that produces a schema for the WSDL contract, yet allows you to control how the message parameter is processed. THus, you can deserialize the XML yourself into your ORM entities, and save overhead of the service model deserializing to data contract types, then remapping those to ORM types. This gives you the separation you need, with the optimization necessary. The best of both worlds.

The drawback is only that you have to process the XML.

Here is a sample: http://www.dasblonde.net/downloads/IXmlSerializable.zip

And I wrote about this and all things contracts in Chapter 2 here: http://www.thatindigogirl.com
George Clingerman
Hi Michele and Sinclair.

Thanks for your help - both of you.

And Michele, you are absolutely right, I am at #3 and I thought this was a "classic dilemma". I will check out the approach you mentioned with IXMLSerializable type.
However, from what you wrote in your answer, I (or the WCF framework) always need to do the serialize/deserialize of the data contract. The step I am saving is the mapping from there and to the entities, right

Anyway I will check your example - and thumbs up for the good site, I am a regular visitor

Regards

Henrik
DataContract vs persistence model - Guidance needed

Answer this question