views:

101

answers:

2

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.

+1  A: 

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.

Stefan Steinegger
Thanks - just to clarify, I'm not interested in the clients at this stage. I'm purely thinking about how best to marshall requests and data from the service layer of my Service to the Business Logic Layer of my service.
ng5000
In our system, only BOs exist on the business logic layer. DTOs are in the service layer only.
Stefan Steinegger
How do you find the ongoing maintenance cost? Every time a property changes you end up having to edit both the BO and the DTO...what does the DTO actually give you?
ng5000
@ng5000: IMO, maintenance costs are not that high. We also were worried about the "you have to add the property at several places" problem. But I think, it is not much work. Maintenance is much better if you don't reuse anything, because your layers will become more independent. See also my blog post about Evil Dry: http://geekswithblogs.net/StefanSteinegger/archive/2010/04/16/evil-dry.aspx
Stefan Steinegger
A: 

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.

Paul Speranza
Sounds a little bit like an anemic domain model (http://en.wikipedia.org/wiki/Anemic_Domain_Model), which is usually viewed as an anti-pattern. The problem is that the business logic tends to get scattered around the BLL.
ng5000
We also started with this model and are still spending a lot of time to move away from it. It may work in smaller systems. We have a huge system, there it is more important to make its parts independent. Unless you can't change anything without influencing every part of the system.
Stefan Steinegger
Paul Speranza
What would you like me to elaborate on?
ng5000