The N-Layer POCO/ DTO quandary

Question

When there were only evil datasets and the microsoft application blocks your transfer objects between layers would be either datasets/datatables or DTO/POCO. I belong to the gang that likes using DTO/POCO.

Now with this sudden wave of mapping layers like SubSonic, Entity Framework, NHibernate etc, should I still be using my favourite POCOs?? I do this mostly and when working with ASP.net webforms 99% times end up using ObjectDataSource for binding to controls and the features specific to each type.

Should I give up this love for POCO and pass around IQueryables or Entities or things like that and make use of other DataSource objects??

What are the pros and cons of using these objects instead of DTOs ?? How will it hit my app design and performance?

EDIT: When will I get to use the other datasources like Linq Datasorce and Entity datasource etc?

Answer 1

Long live POCOs and DTOs. They are lightweight, easily serializable, strongly typed, bindable. Never had any performance issues with them, always made my higher level code cleaner.

Answer 2

Use nHibernate or another ORM that can map to POCO:-) Then you can decide to pass DTO or POCO based on how much seperation you want between your producer and consumer.

The question I'd ask is are you goign to pull the data into Entities / IQueryables and then convert them to DTO's? This is a very valid pattern especially if your going to transition a service boundary and don't want to expose your domain model; however there is a trade off. A minimal performance hit depending on the size of the data but that's something you'd need to measue.

Recently I had to display a list of a bunch of Organization objects in a drop downlist. Organization has lots of properties and other child objects. None of which I needed for my drop down all I needed was an ID and the name, and a couple of extra properties...

Here's my HQL query to search the DB and return a list of DTO's using nHibernate:

      return CurrentSession.CreateQuery(
            "select new OrganizationListDTO(o.Id,o.Name,o.xxx,o.xxx)" +
            " from Organization i where i.State=:state")
            .SetParameter("state", state)
            .List<IOrganizationListDTO>();

Point here is that even if your using an ORM you can still leverage DTO's for report like queries and let it do all the heavy lifting.

Answer 3

I find parallel object trees for domain and DTO to be repugnant. The extra code to be maintained isn't buying me much, even if I use code generators. I think that layer purity is oversold. I'm not a DTO fan.

Answer 4

I am at the cross roads on this one, too. With SOA, there are other principles one must consider in addition to the technology constraints - well that is if you want to stay on the right track. I've seen some take this debate a step further (including myself initially) and question how to exchange business objects (BOs) around. But I began to realize this violates one of the most fundamental SOA principles - autonomy. Doing this suddenly binds your services to the business specifics. This is just a scenario I wanted to bring up to compare to the DataContract and "Entities" issue. I think the principles are what counts more so - even for the cost of a little redundancy (i.e. dedicated DTOs). I've leaned more toward an adapter pattern for this, to keep the messaging "infrastructure" and a rich component-oriented model like an EDM seperate. Further, making this "adapter pattern" an all-out entity service candidate makes it more elegant, reusable, and autonomous in the SOA world. Thomas Erl describes this notion of "Entity-centric services" with excellence in his book, Service-Oriented Architecture (Concepts, Technologies, and Design). Another thing to ponder: What if my "entity" doesn't reside in a single source (i.e. part in a database and part in a text file or spreadsheet)? With accepting that extra effort with the DTO and/or fully fledged entity-centric service, you can hide that away and promote much higher agility.

Bottome line: If you don't care about SOA principles and are developing more "ad hoc" then take your pick. But if you are in an enterprise or B2B position and simply cannot risk the infamous "ad hoc creep" that SOA intends to tame, then you will probably do SOA entity-centric services as first class citizens and manage them as such. Consider where computing is going (SOA, SaaS, PaaS, etc.), and the paradigms and principles they share.