DTO and Domain Object, WCF as well as DB Layer interaction

Question

I have asp.net mvc 2 application. i have confusion creating DTO and domain entities.

MVC Controller Integration points: 1) third party WCF 2) DB Layer

WCF is returning Persons information of a particular company and some information about company.

I have generated proxy of WCF and written a service wrapper on the proxy. Service wrapper is talking to WCF and Mapping the results to DTO clas ContactsDTO Service layer is in different project.

Following are my domain classes

Company
Person

DTO class
//it contains
class ContactsDTO
{
Person person, Company[] company
}

Controller action calls the wrapper with companyID and get the object of DTO class. and update the company information from dto. it updates the company information in Session and pass the Company[]array to some other operations.

DB interaction:

Now depending upon some business logic, i have to insert Person-ids and company id along with some other information in Database.

for this i have created another

class DBDTO
{
Person person, Company[] company, OtherInfo otherInfo[]

}

this DBDTO is prepared and passed to DB Layer(which is using Linq to sql).

Questions

Is it write way to do. Any improvement in DTO interaction? What all changes i can do to improve the overall architecture

DTO, as it states in its name is data transfer object. It should be used just for transfer and should not encapsulate domain objects, nor database objects. That said, your DB layer could have some specific objects, for example DBObject, which are directly mapped from/to DTOs, and DTOs on client side are directly mapped from/to client side objects for example ClientEntity. There is a lot of infrastructure code and mapping, yes, but in the end you'll have clean, independent code of client and DB layer domain objects. — Algirdas

Dmitry Frenkel Dmitry Frenkel · Accepted Answer · 2013-03-24T23:29:14

Another alternative to DB-bound objects being translated to DTOs (which takes time) is to use POCO (Plain Old CLR Objects) and use them directly as your Domain Model, objects that can be stored in the DB and objects that are communicated to Controllers for visualization. This can get you started: Working with POCO Entities

This approach has several advantages

Your POCO entities are independent of the underlying DB implementation
Your POCO entities can be unit-tested without presence of a Database
You can easily serialize them into a service response (if you are building an API) using DataContractSerializer or DataContractJsonSerializer

DTO and Domain Object, WCF as well as DB Layer interaction

2 Answers