6

Main advantage with Hibernate annotations is the fact that a simple POJO (also called a Business Object the most of time) can become persistent through Hibernate annotations (or actually JPA) .

In the scenario where our conceptual domain model (business objects used by clients) does not exactly reflect the physical model (database), how to deal with? Should I create a "second" model that represents the "true" business objects used by clients AND a "data storage object" containing mapping Hibernate annotations? Of course, with this solution, DAOs will be responsible to convert each BO to Data Object and vice-versa.

gnat
  • 21,442
  • 29
  • 112
  • 288
Mik378
  • 3,838
  • 7
  • 33
  • 60
  • are you just talking about mapping attribute->column names or is there some class->table mismatch? – leonigmig May 13 '12 at 11:23
  • I talk about class->table mismatch – Mik378 May 13 '12 at 11:43
  • You need to set a policy regarding data access. Either you follow the OO approach or the table-based (store) approach.The capabilities of your ORM and GUI binding options may affect your decision significantly. The Object-Relational impedance mismatch may be a good read: http://www.agiledata.org/essays/mappingObjects.html#ShadowData and http://www.agiledata.org/essays/impedanceMismatch.html – NoChance May 13 '12 at 15:29

3 Answers3

6

You may also think of an alternative representation. Consider the objects used by clients as an "interface objects". A DAO objects then may be used as a truly "business objects".

The business objects may (and usually have to) be tightly coupled with database to communicate with it in a most efficient way.

An interface objects, on the other hand, form an API. An API has it's own requirements, which don't necessarily suit well with what DAO provides:

  • A DAO object may expose the data, which should not be exposed to clients, such as passwords.
  • A DAO data representation may differ from what client needs. For example, the same password field can be hashed in database, while the client code operates with a non-hashed variant.
  • A DAO object may contain data not intended for direct manipulation by clients. Again, a password may be set during registration or checked for correctness, but not read.
  • An interface objects may often have additional requirements applied by the framework they used by, such as JSF or RMI.
lorus
  • 497
  • 1
  • 3
  • 10
1

I think there are some misconceptions about some of the terms you used:

  1. Conceptual domain model is not "business objects used by clients". It is a "model" of that, of business domain.
  2. "Physical model" is not clear, what does it mean. When someone says "physical", it is not necessarily the third phase of database design (after conceptual and logical). Typically if you are talking within the context "domain modeling", mismatch between the model and physical word, refers to conceptual model and business domain, not database.
  3. If you are following a domain-driven-design approach (especially With Hibernate which can automatically create the database based on domain model and ORM), then you design youR Domain Model first, then built the rest of application based on it. In this case, your database will be driven by the domain-model and there won't be discrepancy between the two.
Nazar Merza
  • 406
  • 2
  • 5
  • 1
    I like your third explanatation :) I worried about creation of model based on existing database model. But you're right, domain design first with DDD :) – Mik378 May 13 '12 at 18:25
-2

Have a look at ibartis (mybartis.org) When Im working with a database model that doesn't directly reflect the domain model then I usually use ibartis instead of Hibernate.

LinuxMonkey
  • 1