Skip to main content
Software Engineering

Return to Question

replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 1

This is somewhat similar to this questionthis 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.

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.

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.

Source Link
Adam Rackis
Adam Rackis
  • 300
  • 1
  • 8

Do ORM POCOs replace domain entities?

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.