Skip to main content
Software Engineering

Return to Question

minor typo corrected
Source Link
gnat
gnat
  • 20.8k
  • 29
  • 115
  • 295

When Business Object fields should not excatlyexactly reflect database columns

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.

When Business Object fields should not excatly reflect database columns

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.

When Business Object fields should not exactly reflect database columns

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.

Source Link
Mik378
Mik378
  • 3.9k
  • 7
  • 35
  • 61

When Business Object fields should not excatly reflect database columns

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.