Domain model objects in session

Discussions

General J2EE: Domain model objects in session

  1. Domain model objects in session (2 messages)

    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

    Threaded Messages (2)

  2. Domain model objects in session[ Go to top ]

    Hi Jay,
    I'm not convinced is such an issue to expose business domain objects to your view tier. The reason why I say this is because in traditional MVC apps, as long as the communication is downwards (view to controller to model), then you're safe. This means that the view can talk to Accounts, Customers etc as indeed can any client of the model. To me, the most crucial thing is to not let knowledge of the view or controller layers into the model layer, i.e. Accounts and Customers should know nothing about views and controllers.

    I must admit that I don't use DTOs; I'm a bit of a OO purist and don't like using transfer objects. But that doesn't mean they're not valid of course. I'm open!

    Andy
  3. Domain model objects in session[ Go to top ]

    It gets a bit more complicated when your GUI isn't co-located in the same JMV (ala web tier). For example, with a thick client, you really *do* need to use DTOs, or VOs to avoid network overhead.

    Col