Announcement Announcement Module
No announcement yet.
Architectural discussion when using declarative transactions Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Architectural discussion when using declarative transactions


    I have an application that uses Spring declarative transaction support. My app has three layers:

    1) Presentation layer --> JSF
    2) Business layer
    3) DAO layer --> Hibernate

    Regarding layer 2, I defined a template Business Object (AbstractBO) in order to provide with common CRUD functionality to any of my objects by simply extending this abstract class.

    Then I realized that, due to the fact that BOs where wrapped by the Spring transactional proxy, some exceptions could be thrown not catched by my BOs (as they are proxied), so I defined an abstract Business Delegate (AbstractBD) in order to catch those exceptions (normally exceptions from the Spring transaction API).

    But I don't know if having to define this extra layer (AbstractBD) is the right solution, because to, for example, save an object into the DB, I have to call the BD, which in turns calls the BO, which in turn calls the DAO. Maybe too many classes or maybe just necessary classes.

    So my question would be what do you think about this approach, and if it were possible to catch exceptions from the proxied BOs...