Data Mappers vs Data Services generated classes

Jul 11, 2009 at 12:17 AM

Hi there,

I was just browsing the code of the Aqua project when I notice that it's using a Data Mapper to map the classes generated by the Ado.Net Data Services into C# POCO class. Can someone put some comments on the pro/cons of implementing the mapper as compare to using the generated classes directly?

Thank you,


Jul 13, 2009 at 6:28 PM

Hello Tony,

There will be a blog post very soon on this topic, but here is the quick explanation.  We used separate model classes instead of the generated classes for two main reasons. 

1).  We wanted to keep the model separate from any datasource or database.  Keeping the Model separate like this will allow us to connect to any datasource with the correct information and with a little modification in the service calls, have the project work as planned. 

2).  We did not want to put any behavior inside of the generated classes.  In the future, if we need to make the aqua project CRUD capable, it will not be a good idea to put behavior to support that in the generated model classes. 

I hope this helps.


Jul 15, 2009 at 8:20 PM

Hi Steve,

Separating the data layer related classes and keeping the model pure is always a good idea. However, I wonder whether that approach will require one additional copy operation: from the data layer class to the pure model class. I haven't look too deep in to the Aqua project code, but from what I've seen, it seems to do just that.

Btw, since we're in the subject of pure model class, I wonder whether the POCO capabilities of MS Entity Framework 4.0 can be extended to Data Services. I will appreciate your thoughts on this.

Thank you,


Jul 20, 2009 at 8:25 PM

Hello Tony,

Yes, there is some overhead with what we are doing.  We are basically treating the generated classes as DTO's (Data Transfer Objects) and there is a direct copy from the generated class to the model class.  We have a little overhead, but we gain scalability.  Now we can use whatever datasource and service that we want because the model is totally independent from the service and datasource.  We are actually looking into some other technologies to demonstrate the flexability of designing it this way.  Stay tuned.

For your other question, the POCO's will be generated when coming from the service, and we will still want to keep all behaviors out of the generated classes. 

Also, it may look like a one to one mapping between the generated and model classes, but that may not always be the case. 

Hope this helps.

Steve Osterberg