Sharing content between business objects and DTOs

Question

All,

My typical approach for a medium sized WCF service would be something like:

1. Define the interface using WCF data contracts and service operations. The data contracts would be POCO DTOs with no CRUD or domain logic.
2. Model the domain using fully featured business objects.
3. Provide some mechanism to go from DTO to BO and vice versa (see related question: http://stackoverflow.com/questions/3123167/pattern-strategy-for-creating-bos-from-dtos)

Now, a lot of the time (if not always) the data content of the business object and the DTO is near identical. How do people feel about creating a library of content objects which are shared by the BO and the DTO. E.g. if we had a WibbleDTO and a WibbleBO, we could create an IWibbleContent interface which both implement. We could even create an IWibbleContent interface and a WibbleContent class which both the DTO and BO hold a reference to.

So, specific questions:

1. Do you ever share content/data interfaces between your DTOs and BOs?
2. Do you ever share data content classes between your DTOs and BOs?

If not then I guess, as per my related question, we're left with tedious copying code, or we use something like AutoMapper.

Any comments appreciated.

Answer 1

We are using quite similar approach as you describe with DTOs and BOs.

We rarely have common interfaces, either they are very basic (eg. interface to get BusinessId) or they are specific for a certain implementation, eg. a calculation which could be made on the client or on the server.

We actually just copy properties. They are usually trivial enough that it is not worth to share code.

At the end, more code is different then similar.

• We have many attributes on these classes, which almost never are the same.
• Most Properties are implemented as get; set; on the server, but with OnPropertyChangedEvent on the client, which requires the use of explicit fields.
• We don't share much code on client and server side. So there is no need for common interfaces.

Even if many of the properties are the same on both classes, there is actually not much to share.

Answer 2

I usually create POCOs and use them through all of my layers - data access to business to ui. In the business layer I have managers that have the POCOs pased back and forth. We are going to look at the Entity Framework and/or NHibernate so I am not sure where that will lead us.

Yeah, we write some extra code but we keep everything lean and mean. We are using MVC for our UI which for me was a godsend compared to the bulk of webforms, I'll never go back. Right now our battle is should we send JSON to the ajax callbacks or use partial views, the latter is what we do most of the time.

Are we correct? Maybe not but it works for us. So many choices, so little time.