How to use DTO's between UI, BLL, DAL

Question

I'm trying to write a small app with very strict boundaries between BLL and DAL and am now wondering what the best way would be to pass the data (Domain Transfer Objects) between the layers.

I implemented some classes in a Domain Level (class library) that is accessed by both BLL and DAL. These classes basically just contain properties/data members and currently reflect the DAL data. Ex:

class CustomerData
{
  // some data fields
}

Then I implemented some classes in BLL as :

class Customer : CustomerData
{
  // Some methods
}

In my DAL I get the customer records from the database through Linq-to-Sql. I then map the linq object to my Domain object by:

CustomerData.field = LinqObject.field
// Etc

My thinking is thus that I now a CustomerData instance from my DAL to BLL when requested (and that I should pass a Customer instance to my UI).

In my BLL I will thus receive a CustomerData instance, but now I want to make a Customer out of it.

Questions:

1. Do I have to in my BLL now create a Customer instance and AGAIN copy all field members ?
   Customer c = new Customer; c.field = CustomerData.field;
2. How can I create a Customer from the CustomerData without the field copy steps ?
3. Should I rather then use composition ?
   class Customer { CustomerData Data; }
4. Is there a more effective way (less coding etc) to do this in my current layout ?
5. Is there better ways to do this ?
6. Any comments in general ?

Thanks !

Answer 1

generally I consider DTO's to be non layer specific, created/consumed by DAL, processed by BLL and consumed/created by UI.

usually each layer is a separate project in the VS solution folder, the DTO's therefore are another project which is referenced by each layer.

this way if there is a field that needs to exist in the UI but not in the other layers, the DTO can be inherited from.

Answer 2

Some notes from my point of view comes here, I'm not an oracle but hopefully it will give some help :)

To me it feels that you have too many "models" here. It might cause confusion and lead to a lot of code just to copy data between different representations. And lot of code means more bugs. Then, I think that the inheritance between your Data-classes and business-classes kinds of limit you when defining your business classes. How about if you want to create a business class that is composed by several data-classes? You should rather use interfaces or composition I think.

Usually, I work with only one conceptual model reflecting the business domain. This model is used both by the data and the business layer and in some cases even the presentation layer (in smaller apps), as Dead Rabit points out. For persistance I use an O/RM such as EF 4.

For larger projects, especially in distributed scenarios I use custom DTO's for the UI-layer(s). These classes reflects the needs of the UI, and could differ a lot from the entities in the conceptual model.

Personally, I think Entity Framework 4 helps you a lot when building apps according to this structure, if you are at an early stage of your project and uses .NET 4 you might want to check it out?

1. Yes, you probably need to.
2. Use composition
3. Yes, I would use composition
4. Use for example Entity Framework 4
5. (-"-)
6. see above