Loading ...
Sorry, an error occurred while loading the content.
 

Object Persistence - Hibernate

Expand Messages
  • Ismet E. Kahraman
    EmployeeData eData = DAO.getEmployee( ismet ); Employee ismet = new Employee(eData); PayRoll payroll = ismet.pay(); payroll.print( new Printer() ); PayRollData
    Message 1 of 4 , Feb 3, 2005
       
       EmployeeData eData = DAO.getEmployee("ismet");
       
       Employee ismet = new Employee(eData);
       PayRoll payroll = ismet.pay();
       payroll.print( new Printer() );
       
       
       PayRollData pData = payroll.getData();
       eData = ismet.getData();
       
       DAO.save(pData);
       DAO.save(eData);
       
       
       In the code above, I am trying to isolate OR-Mapping issues completely from
       domain model. And trying to keep Domain Objects as much behaviorally rich as possible.
       Here, (Employee and PayRoll) are Domain Objects, and (EmployeeData and PayRollData) are
       data aspects of these objects.
       
       After this separation, the persistence will be done via these Data suffix objects
       representing persistent aspect of domain objects. And code will never depend on any
       OR-Mapping tool.
       
       What do you think about this kind of approach? Will it pull its weight? And what do you
       think about normal hibernate approach (I mean using domain objects as persistent objects)?
       
       Thanks in advance.
       
       ismet kahraman
       
       
       
    • Ahmed Hassan
      Hello, I have a few suggestions, not sure if they fit your vision. 1- you can map the domain objects directly. If you want to exclude some part of the domain
      Message 2 of 4 , Feb 3, 2005
        Hello,
         
        I have a few suggestions, not sure if they fit your vision.
         
        1- you can map the domain objects directly. If you want to exclude some part of the domain object for persistence, I think that should go in the mapping area (not in the domain). Hibernate mapping can be XML files which references to the classes/attributes you want to persist .
         
        If you go this way, you won't need the data objects for persistence at all. Hibernate would instantiate the DO for you and you can call save on it.
         
         Employee ismet= DAO.getEmployeeByName("ismet");
         PayRoll payroll = ismet.pay();
         payroll.print( new Printer() );
         
         DAO.save(ismet);
         DAO.save(payroll );
         
        NOTE: I would try to go like this, with any OR mapping tool, not only hibernate.
         
        2- Hibernate session 'remembers' what objects it loaded and it 'knows' if they changed and saves them. I assume you mean the J2EE hibernate. So, if your objects don't cross sessions, no need for the explicit save commands.
         
        // DAO will init the session at some point
        Employee ismet= DAO.getEmployeeByName("ismet");
         PayRoll payroll = ismet.pay();
         payroll.print( new Printer() );
        // DAO will close the session at some point
         
         
         
        3- if your objects cross sessions (or if your OR mapping doesn't 'remember' what needs to be saved and you want to do it yourself), I would try to keep track of loaded objects in a separate layer outside of the domain objects (unit of work layer:   http://www.martinfowler.com/eaaCatalog/unitOfWork.html )
         
        IMHO saving objects is not omain business.
         
         
        HTH, please let me know if you have any questions
         
        Ahmed 
         
         
         
         
        ----- Original Message -----
        Sent: Thursday, February 03, 2005 4:59 PM
        Subject: [agileDatabases] Object Persistence - Hibernate

         
         EmployeeData eData = DAO.getEmployee("ismet");
         
         Employee ismet = new Employee(eData);
         PayRoll payroll = ismet.pay();
         payroll.print( new Printer() );
         
         
         PayRollData pData = payroll.getData();
         eData = ismet.getData();
         
         DAO.save(pData);
         DAO.save(eData);
         
         
         In the code above, I am trying to isolate OR-Mapping issues completely from
         domain model. And trying to keep Domain Objects as much behaviorally rich as possible.
         Here, (Employee and PayRoll) are Domain Objects, and (EmployeeData and PayRollData) are
         data aspects of these objects.
         
         After this separation, the persistence will be done via these Data suffix objects
         representing persistent aspect of domain objects. And code will never depend on any
         OR-Mapping tool.
         
         What do you think about this kind of approach? Will it pull its weight? And what do you
         think about normal hibernate approach (I mean using domain objects as persistent objects)?
         
         Thanks in advance.
         
         ismet kahraman
         
         
         
      • Ismet E. Kahraman
        My point is that hibernate as an OR tool is somewhat intrusive to domain model objects by means of set-get methods that must be provided in order to operate
        Message 3 of 4 , Feb 3, 2005
          My point is that hibernate as an OR tool is somewhat intrusive to domain model objects
          by means of set-get methods that must be provided in order to operate with it.
          And trying to achieve a complete independence and after writing down the domain objects,
          delving into the OR mapping issues.
           
          So, is it wise or feasible or logical to employ
          Data objects which are just data holders and putting these objects between Domain objects and
          OR tools?
           
          In this link, proxy is provided as a means of complete unawareness of persistence aspect.
          And it is encouraged to use Data objects as I've mentioned above. The second question is this:
          OR Tools (hibernate) eliminates the need of employing Proxy pattern in this manner as they
          allows to persist the objects directly?
           
          ismet
           
          ----- Original Message -----
          Sent: Thursday, February 03, 2005 11:31 PM
          Subject: Re: [agileDatabases] Object Persistence - Hibernate

          Hello,
           
          I have a few suggestions, not sure if they fit your vision.
           
          1- you can map the domain objects directly. If you want to exclude some part of the domain object for persistence, I think that should go in the mapping area (not in the domain). Hibernate mapping can be XML files which references to the classes/attributes you want to persist .
           
          If you go this way, you won't need the data objects for persistence at all. Hibernate would instantiate the DO for you and you can call save on it.
           
           Employee ismet= DAO.getEmployeeByName("ismet");
           PayRoll payroll = ismet.pay();
           payroll.print( new Printer() );
           
           DAO.save(ismet);
           DAO.save(payroll );
           
          NOTE: I would try to go like this, with any OR mapping tool, not only hibernate.
           
          2- Hibernate session 'remembers' what objects it loaded and it 'knows' if they changed and saves them. I assume you mean the J2EE hibernate. So, if your objects don't cross sessions, no need for the explicit save commands.
           
          // DAO will init the session at some point
          Employee ismet= DAO.getEmployeeByName("ismet");
           PayRoll payroll = ismet.pay();
           payroll.print( new Printer() );
          // DAO will close the session at some point
           
           
           
          3- if your objects cross sessions (or if your OR mapping doesn't 'remember' what needs to be saved and you want to do it yourself), I would try to keep track of loaded objects in a separate layer outside of the domain objects (unit of work layer:   http://www.martinfowler.com/eaaCatalog/unitOfWork.html )
           
          IMHO saving objects is not omain business.
           
           
          HTH, please let me know if you have any questions
           
          Ahmed 
           
        • Ahmed Hassan
          I am all with you about decoupling the DO from the persistence logic. And I agree that having getters/setters just for hibernate is a big noise in the DO ( in
          Message 4 of 4 , Feb 4, 2005
             
            I am all with you about decoupling the DO from the persistence logic.
             
            And I agree that having getters/setters just for hibernate is a big noise in the DO ( in some cases your getters/setters will have logic that you want to keep away from hibernate). Recent releases of Hibernate have a fix for this issue and allow for 'field' access which does not require setters/getters.
             
             
            About using the proxy pattern,
            My objection to that is the smell of duplication. You will need to 'map' your DO to the DTO (lots of getters/setters, possibly in the DTO constructor). Then you will map the DTO again using hibernate xml. This seems to be some sort of duplication. If you add an attribute or change an existing one, you will repeat the fix twice (in the DTO and the xml). Another issue is what will be the case for complex domain objects  (objects with sets of other objects that has sets of other objects, etc). You will need to do much of the things hibernate does to convert your DO to DTO and to get it back when loading a DTO. Things will be much easier, IMHO, if you concentrate on domain logic and let hibernate persist/load your objects.
             
             
            Another question that I came across is, do we really want to have our Domain objects 100% 'clean' of any persistence traces?
            For example, having dummy/private getters/setters just for hibernate to access the fields is bad (IMHO). It clutters your DO and adds lots of noise. DOs need to be clean of that.
             
            But, for the mapping xml, it can be hand maintained in separate xml files (so that the DO has no persistence traces), or can be generated from xdoclet comments in the DO. We had to keep separate xml files since, at the time, xdoclet didn't support certain hibernate features that we needed (namely the 'field' access mentioned above). If that was not an issue, I would want to keep the 'mapping' in the DO (as comments) even though it will make it less pure. This way when you add/change/delete attributes, you do it in one place (well,  2 places next to each other in one file), as opposed to a java file and a separate xml file.
             
            I wonder what other members of the group think about this point.
             
            Ahmed
             
            ----- Original Message -----
            Sent: Friday, February 04, 2005 9:58 AM
            Subject: Re: [agileDatabases] Object Persistence - Hibernate

            My point is that hibernate as an OR tool is somewhat intrusive to domain model objects
            by means of set-get methods that must be provided in order to operate with it.
            And trying to achieve a complete independence and after writing down the domain objects,
            delving into the OR mapping issues.
             
            So, is it wise or feasible or logical to employ
            Data objects which are just data holders and putting these objects between Domain objects and
            OR tools?
             
            In this link, proxy is provided as a means of complete unawareness of persistence aspect.
            And it is encouraged to use Data objects as I've mentioned above. The second question is this:
            OR Tools (hibernate) eliminates the need of employing Proxy pattern in this manner as they
            allows to persist the objects directly?
             
            ismet
             
            ----- Original Message -----
            Sent: Thursday, February 03, 2005 11:31 PM
            Subject: Re: [agileDatabases] Object Persistence - Hibernate

            Hello,
             
            I have a few suggestions, not sure if they fit your vision.
             
            1- you can map the domain objects directly. If you want to exclude some part of the domain object for persistence, I think that should go in the mapping area (not in the domain). Hibernate mapping can be XML files which references to the classes/attributes you want to persist .
             
            If you go this way, you won't need the data objects for persistence at all. Hibernate would instantiate the DO for you and you can call save on it.
             
             Employee ismet= DAO.getEmployeeByName("ismet");
             PayRoll payroll = ismet.pay();
             payroll.print( new Printer() );
             
             DAO.save(ismet);
             DAO.save(payroll );
             
            NOTE: I would try to go like this, with any OR mapping tool, not only hibernate.
             
            2- Hibernate session 'remembers' what objects it loaded and it 'knows' if they changed and saves them. I assume you mean the J2EE hibernate. So, if your objects don't cross sessions, no need for the explicit save commands.
             
            // DAO will init the session at some point
            Employee ismet= DAO.getEmployeeByName("ismet");
             PayRoll payroll = ismet.pay();
             payroll.print( new Printer() );
            // DAO will close the session at some point
             
             
             
            3- if your objects cross sessions (or if your OR mapping doesn't 'remember' what needs to be saved and you want to do it yourself), I would try to keep track of loaded objects in a separate layer outside of the domain objects (unit of work layer:   http://www.martinfowler.com/eaaCatalog/unitOfWork.html )
             
            IMHO saving objects is not omain business.
             
             
            HTH, please let me know if you have any questions
             
            Ahmed 
             
          Your message has been successfully submitted and would be delivered to recipients shortly.