Discussions

EJB design: Entity Beans behind DAOs

  1. Entity Beans behind DAOs (3 messages)

    Good morning (well, at least in this part of the world)!

    This is my first post here at TSS, so please correct me if this is not the appropriate forum for this.
    I would appreciate your input on the following: I tend to implement my entity beans behind a layer of abstraction, which I call DAO, just as with JDBC and other integration technologies. My reasons for doing so are:
    1. It gives me freedom to change implementation (for example if later I realize JDBC would do better) without breaking client code;
    2. It conceals infrastructure code, as JNDI lookups and cumbersome low level exception handling;
    3. It conceals all persistence logic, including some integrity checks I might need to do myself (not enforced by the DB, or across different technologies, say JCA and EJB);
    4. It allows me to present a uniform API, including a technology agnostic exception hierarquy (a la Rod Johnson in J2EE Design and Dev.)

    It´s not usual to see advice about using DAOs with entity beans, but I find it interesting. I´m sure the community must have a lot of opinions on this, and I´d love to hear them.

    Cheers,
    Eduardo

    Threaded Messages (3)

  2. 1. It gives me freedom to change implementation (for example if later I realize JDBC would do better) without breaking client code;
      This is usually acomplished by having a DAO under the Entity bean.
    2. It conceals infrastructure code, as JNDI lookups and cumbersome low level exception handling;
      The Façade patern is typically used to acomplish this.
    3. It conceals all persistence logic, including some integrity checks I might need to do myself (not enforced by the DB, or across different technologies, say JCA and EJB);
      This could also be done in a DAO layer under the EJB layer.
    4. It allows me to present a uniform API, including a technology agnostic exception hierarquy (a la Rod Johnson in J2EE Design and Dev.)
      The Façade patern is typically used to acomplish this as well.
    It´s not usual to see advice about using DAOs with entity beans, but I find it interesting. I´m sure the community must have a lot of opinions on this, and I´d love to hear them.Cheers,Eduardo
    I have used DAOs under entity beans, and had a façade in front of the entity bean. With this you get all the benefits of the situation you are describing above.

    One big issue I see with placing DAOs in front of the entity beans is that the entity beans do a lot more than access data; such as transactions, caching and pooling. If you where to have EJBs be one implementation, you could not leverage all the powers of the entity bean unless you required all future implementation of that DAO to implement the used functionality as well.

    My advice is to use the DAO pattern, but dump the Entity beans :)
  3. Entity Beans behind DAOs[ Go to top ]

    Good evening Eduardo (here in the UK at least).

    I think you have a great approach in using the DAO design pattern to abstract away from the underlying persistence technology. As you point out this gives the ability to swap between Entity Beans, JDO, and anything else you care to use later on.

    Many people have not quite grasped the power of DAO in this context.

    You may be interested in this article on why it is a good idea to use the DAO design pattern in the way that you are using it:

    http://www.codefutures.com/products/firestorm/benefits/

    Also you might be interested in FireStorm/DAO which generates DAO interfaces from a database schema and gives you the choice of generating implementation code based on JDBC, Entity Beans or JDO.

    http://www.codefutures.com/products/firestorm/

    Cheers,

    Andy Grove
    Code Futures, Ltd.
  4. Hello!

    Thanks for the input!

    Caching, pooling and transactions go unaffected, the way
    I see it.
    The good thing about those services is that they are
    transparent to the bean´s client, in a way that they do
    not couple the DAO interface to the tecnology.
    The DAO abstracts away the complexity of looking up the
    bean, handling the exceptions and so on. It also presents
    the same interface and exception hierarchy, whichever
    the implementation. I wouldn´t have this benefit if I
    chose to implement the DAO behind a BMP.

    Matthew, I do see your poing, but I choose to implement
    behind a DAO because the code is pertinent to persistence
    logic, and seems to me a good candidate for abstraction.

    Cheers,
    Eduardo