Announcement Announcement Module
No announcement yet.
Business Facade, Hibernate, transactions and security Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Business Facade, Hibernate, transactions and security

    Hi all, my team and I are discovering spring and hibernate and we are very enthusiastic about it. We are trying to define good general design principles before starting on some big applications. I'd like to share some of our conclusions with whoever is interested and/or want to say something about it.

    For now, our application framework look like this:

    - spring web mvc (with OSIV interceptor)
    - spring-defined transactional proxy
    - business facade interface
    - business facade implementation
    - pojo domain objects
    - dao interface
    - dao hibernate implementation

    We have decided to put the transactional level at the business facade level. In order to be able to browse hibernate objects in views, we use the OSIV interceptor.

    To make sure invalid form submission never lead to invalid data persistence, we have a "checkOut(Object)" on the facade, which is just a wrapper around "checkOut(Object)" on our DAO, which ends up calling evict() in hibernate. That way the objects we use in the MVC for CRUD operation are unplugged. To get them back to the database, we have a similar "checkIn(Object o)" method (calling merge() in the hibernate template).

    So, basically, when I want an object in the map to display some of its properties, including browsing the collection, I call the relevant getObject() on my business facade and put the result, a "persistent" instance, in the map. When I want a "sandbox" object for formBackingObject(), I had a simple checkOut() after the get..()

    We were quite happy with this approach, and started wondering the way we should deal with security and access rights... We can implement security at the page level, but I have been toying with the idea of lowering the security at the facade level. The problem here would be how to make sure the view does not change objects that were just meant to be browsed ?

    I guess I could add a layer on top of the business facade in order to proxy all my pojo with a security proxy.
    I could also work with three "species" of pojo, some connected but readonly (private setters), some disconnected for CRUD forms, some connected and read-write for internal use in the facade...
    And... I could also stick to good old web MVC level security

    Any thought welcome...