Data Access and Data Contracts

Topics: Service Factory Modeling Edition Forum
Jun 21, 2007 at 10:43 PM
Edited Jun 21, 2007 at 10:45 PM
In my company, we have a project where the Data Contract for a service was made up of multiple Business Entities. These Entities were basically representations of database tables because generation of them (including the repository classes and the CRUD SPs) by Recipes was so easy. There was a need to provide some business logic against the data as it stood in the Data Contract. The choice was made to push the Data Contract down to the Business Logic, peform any validation and business rules, and then perform the translations into the separate Business Entities to save down to the database.

Considering the future of ADO.NET and LINQ for Business Entity/Data Access modeling and the future of the Services Factory, is this kind of pattern good, bad, neither? It seems to me that, going forward we should be representing the conceptual objects with ADO.NET Entities. And then business rules, authorization, etc. should be performed on the Entities. But then does that mean that Data Contracts becomes a really superficial layer. Couldn't we then create Message Contracts directly from ADO.NET Entities?

Can someone explain to me the bigger picture here in relation to the roles of ADO.NET Entities and Data Contracts going forward in the VS 2007/LINQ/ADO.NET Entities environment?
Jun 27, 2007 at 1:49 AM
Data Contract vs. Business Entity model external and internal representations of data respectively.

This enables separation of the format used for internal representation and the one use accross the service boundary. This is particularly usefull if you need to limit the information exposed depending on the operation being called (which might have different authorization requirements). You might even have different services exposing the same information, because you need al alternate service interface to comply with some standard or a third party application's format.

The entities don't necesarily need to be simple, like in a 1-1 relation with your table. In fact the wcf reference implementation, contains an example where some entities hold references to other entities. Take a look at CreditCardAccount business entity (complemented in CustomerAccountAggregate.cs) and also CustomerAccountSummary. The later holds lists of accounts and credit cards entities.

Even with the previous information, there might be scenarios where the data contract needs to support relationships that are only valid on the service implementation layer. The business rules + validation involved should deal with that specialized service interface scenario, thus I don't think they belong well in a the business logic layer. In the case of having some framework for the business rules or validation which justify its use, I would make sure the implementation don't ends coupled with the data contracts.

On a different topic: In the case one would like to proceed with your vision and unify entities + data contracts, one could modify the templates in the guidance to automatically decorate the entities with the appropiate attributes (modifying the designer if more control is required). As stated before, there is a reason to do this differently.
Jun 28, 2007 at 5:19 AM
I have looked at the reference implementation and have seen how they create business entities that contain other entities. I have also seen how they create a business entity to describe something that is not directly related to the database. The Customer Search Criteria, while it allows a user to search for a customer, does not directly reflect a customer or any specific database table. It seems to me that they could have achieved the same goal by mapping a Customer Search Criteria Data Contract back to a Customer Business Entity, thereby using a well-known Business Entity in an overloaded fashion. This concept would promote the idea that a single Business Entity could be mapped back to from multiple Data Contracts. Instead, it almost promotes the exact opposite, seeming to suggest that you could/should create Business Entities to reflect the data you are receiving from the Service Layer.

Let me play Devil's Advocate here...with ADO.NET Entities, I can create Entities that represent as much or as little of the actual database tables. So I could create many Entities representing the same database tables and fields, customized for what I expect to do with the data in the Service Layer. So I could create an ADO.NET Entity that represents Customer Search Criteria.

Personally, I prefer the idea that I specify true Domain Model Objects in the Business Layer and map back to them from Data Contracts in the Service Layer. When I consider a layered application, I expect each layer to only know about the layer directly below it. So the Service Layer knows about the Business Layer, but not the Data Access Layer. And the Data Access Layer doesn't know about any other layers (unless you count the physical database as a layer). However, I don't expect any layer to know about any layers above it. So the Business Layer doesn't know about the Service Layer. In this fashion, I could create a Business Layer that can be shared among multiple Service Layers. As long as the Service Layer knows how to map back the data to the Business Layer--and as long as the Business Layer supports all the operations the Service Layer needs--then all is right with the world.

While the reference implementation does show how to create richer Business Entities from other, let's call them Table Business Entities, I didn't really see it overloading the use of any given Business Entity by having multiple Data Contracts map back to the same Business Entity. I think this kind of example would show the value of the separation of the Service Layer and the Business Layer. Even the WSSF documentation is a bit double-sided in that, when discussing the Business Layer, it talks about the Business Entities representing your Domain Model Objects. But then when it discusses the Service Layer, it talks about a Domain Model Object being represented by more than one Business Entity--thus making the Domain Model Object only exist as a Data Contract and/or Message Contract in the Service Layer.

In any case, you did help ensure that my view of the use of Data Contracts in the Business Layer is not really a good one. I am looking for some MS documentation or P&P recommendations that show best practices for use of Data Contracts, Business Entities and the best use of them in the Service and Business Layers.

Anyway, thanks for the post. It was helpful.
Jun 29, 2007 at 4:33 AM
You might want to check (service interface pattern):