Announcement Announcement Module
Collapse
No announcement yet.
Domain model objects in session Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Domain model objects in session

    Hello,

    I've read that keeping domain model objects in the middle tier (business services, etc.) and using data transfer objects in the business services interface to communicate between the middle tier and the UI tier (controller, view) is a good option if the application needs to support more than one front end or if the two tiers are distributed. I understand and agree that DTO's represent poor OO design but considering but there is a very good chance that my application will need both a web and a web service interface in the near future this is the architecture i'm targeting. First of all, did I make any bad decisions thus far?

    Assuming what I said above is reasonable, my problem comes in when I start considering the need to tie business model objects to user's sessions both as a read cache but more importantly as a holding point for domain objects that are updated bit-by-bit during one of the application's many multi-step processes (wizards). I don't want to leak the HttpSession (a front end implementation detail) into the business services but I also don't want to leak the domain model into the front end. An O/R service like Hibernate or TopLink might help me solve this problem but both the domain model and the data access (via Spring JDBC) are already implemented so I'm restricted from making that leap. Does this all sound reasonable? If so, can anyone recommend alternative solutions or workarounds?

    I really appreciate any advice.

    Thanks,
    Jeff

  • #2
    1) IMHO, use DTO's only if needed. If your application have 2 front-end (web and web-services) you can keep the web tier on local (no need DTO for web tier), and use DTO only for webservices puropose. In that way you you create DTO only for remoting needs.

    2) To store Domain object in session to edit it and then save it, you can do this, even using JDBC. All you need is to have sufficient information in your domain object to update it. If your domain object properties contain the primary key (usually a technical id), then you can save your domain object regardless using JDBC.

    3) Session is not the usual place to cache domain object. Dao layer is well suited for that kind of cache, specially if you use AOP.

    Comment


    • #3
      Thanks for the feedback.

      How can I cache domain objects on a per user basis in the DAO, as you are suggesting? Are you saying that AOP can help accomplish this kind of caching? I should clarify that when I use the term caching, I'm really talking about working data (intra-transactional data) that needs to span requests.

      Thanks,
      Jeff

      Comment


      • #4
        A common pratice is to pass the object id in request then retrive it with it's id. in your dao there's certainly a method like findById(String id). So you can use a cache here instead of quering the database each time you need it. AOP can help you in doing it properly (with no additional code in your dao), but you can use a custom cache to accomplish this. This way every user benefit from cache. <br/>
        But if you don't need to cache a lot of object in the session (just to span objets throught requests) , using session can be an easer way.<br/>

        Comment

        Working...
        X