POCO's, DTO's, DLL's and Anaemic Domain Models

Question

I was looking at the differences between POCO and DTO (It appears that POCO\'s are dto\'s with behaviour (methods?))and came across this article by Martin Fowler on the anaemic

Answer 1

Typically, you don't want to introduce persistence into your domain objects, since it is not part of that business model (an airplane does not construct itself, it flies passengers/cargo from one location to another). You should use the repository pattern, an ORM framework, or some other data access pattern to manage the persistent storage and retreival of an object's state.

Where the anemic domain model comes in to play is when you're doing things like this:

IAirplaneService service = ...;
Airplane plane = ...;
service.FlyAirplaneToAirport(plane, "IAD");

In this case, the management of the airplane's state (whether it's flying, where it's at, what's the departure time/airport, what's the arrival time/airport, what's the flight plan, etc) is delegated to something external to the plane... the AirplaneService instance.

A POCO way of implementing this would be to design your interface this way:

Airplane plane = ...;
plane.FlyToAirport("IAD");

This is more discoverable, since developers know where to look to make an airplane fly (just tell the airplane to do it). It also allows you to ensure that state is only managed internally. You can then make things like current location read-only, and ensure that it's only changed in one place. With an anemic domain object, since state is set externally, discovering where state is changed becomes increasingly difficult as the scale of your domain increases.