Do ORM POCOs replace domain entities?

Question

This is somewhat similar to this question but more broad.

In general, with ORMs like EF 4.1 supporting POCOs, does it now make sense to have your domain entities be the objects that are persisted to your database?

With older ORMs like EF 4 or Linq-to-SQL, your "database objects" were auto-generated, and tightly coupled to your database, and so, for non-trivial applications, were mapped to more robust, intelligent domain entities before being put to work.

Is the idea with newer ORMs to just build robust domain entities, and then have a data-layer that simply provides a mapping between said domain entities and your DBMS?

In writing that I get the feeling that this has always been the goal, but not readily (easily) possible with the tools available, at least not in the .NET world.

Answer 1

I think the general goal with ORMs is that the database is mapped directly to domain objects, which are ideally POCOs. So the answer to your question is yes. Now that EF is capable of mapping to POCOs it is ideal to consider those POCOs as domain entities. For other ORMs such as NHibernate this has been possible for awhile and I believe people have generally been using them as such.

But this goal of having domain entities directly mapped to the database isn't always achievable. There are some cases where there is a significant translation needed between the database and the domain model. The ORM may not be capable of doing the translation. In this case you might want a layer of intermediate POCOs that are mapped with the ORM to the database and then a translation layer that changes them into domain POCOs and back again.