Reputation: 213
I have a web application that connects to WCF services for its business logic. I would like to use simple Dto's for transfering data at the WCF boundary for performance and interoperability reasons.
However I have to use typed datasets for data access (ORM or any other option is not available due to political reasons).
Is it a good idea to use Dto's along with typed datasets. Have anyone done this? Is there a recommended pattern? And most importantly is there a library/tool/method to auto generate Dto's from the typed datasets?
Upvotes: 1
Views: 875
Reputation: 1341
Entity translation pattern comes to mind.
http://msdn.microsoft.com/en-us/library/cc304747.aspx
Well, maybe a variation on it.
I had to do something similiar recently, and I just created a another "layer" that translates the data stored in the datarow/datatable etc. into the data contract object. The service layer can call this new layer method with the results from your data-access method as a parameter.
Here's a quick and dirty PSUEDOCODE example:
public class personTranslator
{
public static PersonDataContract TranslateToContract(Datarow personDataRow)
{
PersonDataContract resultPerson = new Person;
resultPerson.FirstName = personDataRow["FirstName"];
resultPerson.LastName = personDataRow["LastName"];
.
.
[etc.]
return resultPerson;
}
}
SERVICELAYER Class
public PersonDataContract GetSpecificPerson([Parameters])
{
[other setup/validation code...]
return PersonTranslator.TranslateToContract(PersonDataAccess.GetPersonRow([Parameters]));
}
Upvotes: 2
Reputation: 1031
I would suggest to use typed DataRow-s, DataTable-s. There's really not much difference between a typed DataRow and a Dto object. Performance wise you have to test it that plain Dto-s will help (I doubt it). As for interoperability, typed DataRow-s are plain classes, so they are as interoperable as Dto objects.
Upvotes: 0