3

My ORM is generating objects reflecting the database table structure. This objects are extensible, so I'm able to add new properties and methods. This objects do not contains any persistence logic,so I guess they are persistant ignorant.

Should I use this object as my domain objects or should I create new objects for main domains model ?

As a pro for creating new object I would consider that when a database table changes it won't break the application.

As a con for creating new object I would consider the additional mapping and more complexity in the app.

user256034
  • 4,289
  • 5
  • 37
  • 44
  • "pro for creating new object.... db changes wont break the app" but if your 'new' domain objects are linked to- or wrapping the orm-generated objects won't that link (and thus the app) break as well? – Jeroen May 15 '11 at 11:37

2 Answers2

5

Instead of using your ORM to pull data out of the DB in a form that relates to how the DB sees the data create your domain objects to actually match your domain and then use your ORM to persist your domain objects into the database in whatever way the DB needs.

In other words, you're doing it backwards. Get the domain model right first and then let your ORM worry about how to persist them to the DB.

Russell Troywest
  • 8,635
  • 3
  • 35
  • 40
  • 2
    +1. Using ORM classes as your domain model ties you to the ORM when you really need to be independent. – Adrian K May 15 '11 at 12:19
2

My answer is, it depends. If you have a lot of complex logic assosiated with many entities you should create another layer of domain, but for the objects that got no logic and just serves you as a db port, don't bother to create a separate object cause its meaningless.

To sum up, if a db change will cause domain change, don't separate if it won't, separate.

Chen Kinnrot
  • 20,609
  • 17
  • 79
  • 141