Announcement Announcement Module
Collapse
No announcement yet.
Domain Driven Design (Hibernate) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Domain Driven Design (Hibernate)

    Hello,

    I am having an issue understanding domain driven design. I've got a spring + hibernate application and I have a couple DAO and services objects. I implemented DAO using hibernate. I got a couple questions related to scope of service layer beans:
    a) I am using OpenSessionViewFilter and rely on lazy loading provided by hibernate in some places generating my web pages. This way my DAO implementation sort of affects on presentation level - implicitly. Let's say another DAO implementation would have to emulate lazy loading to get the same effect. This is kinda ok but bugs me since I don't like implicit relations.

    b) Another thing is working with detached objects stored in session you have to merge or update them in context of hibernate session. Therefore my service code looks like:
    dao.updateOrMerge(detachedObject)
    do some logic
    some more dao calls
    Here updateOrMerge method is hibernate specific, let's say for JDBC implementation I don't have to updateOrMerge. So in other words appears that my service is not truely independent on dao implementation. Am I designing something wrong or those are drawbacks of domain driven design?

    Thanks.

  • #2
    Take a look at this thread, where this issue is discussed in some depth:

    http://forum.springframework.org/showthread.php?t=15294

    Yes, it's true that the benefits of OSIV+lazy come at some architectural cost. You can mitigate these somewhat by eager loading.

    In general, working with detached objects is quite an arse, and I'd recommend not cluttering up the session with them if possible, but discarding them and re-fetching them on subsequent requests. This approach is not only more portable but also more efficient - the objects are hanging around in Hibernate's cache anyway. Of course if you are trying to work with long transactions you will need a more elaborate approach.

    These are not actually drawbacks of domain-driven design, but of Hibernate/Java semantics :P

    Comment


    • #3
      Thanks for the explaination, I think it makes sense. Other than that hibernate made my life hard working with detached objects (had to merge all the time) so I already got rid of them and use IDs together with hibernate cache. It works pretty good for me.

      Comment

      Working...
      X