Discussions

EJB design: Static methods vs class instantiation

  1. Static methods vs class instantiation (5 messages)

    Hello

    The Data Access Object pattern (DAO) is a well known pattern that is used with domain models, even when using Entity Beans. However, normally, the pattern involves instantiating extra objects, rather than using static methods.

    So for example, it is not unusual to have an entity bean and 2 additional objects to implement the DAO.

    1)Why not use a class with static methods that implement the JDBC calls? Surely, in a multi-user environment, this would be advantageous for performance and scale? And as far as I can tell, the DAO generally does not encapsulate any data as such.

    2) Equally well, the Entity bean could sure pass a reference to itself (via "this") to the static methods of the Data Access CLass. The DAO class could then populate the entity bean propoerties directly, rather than having to create a plain old java object that essentially is identical to the entity bean, and then having the entity bean copy this data to itself.

    I do realise that the Entity Bean spec prevents an entity bean from returning a reference to itself via "this", but as I described it , I do not se a problem (and it does work!)

    Can someone set me straight please?

    Confused

    Paddy

    Threaded Messages (5)

  2. DAO and interfaces[ Go to top ]

    Hi Paddy,

    The reason you wouldn't use a class with static methods is because the DAO pattern uses an interface for Data Access Objects.

    You couldn't have an implementation class with static methods that implement the interfaces methods.

    e.g.

    public interface DAO {
       public ValueObject daoMethod();
    }

    public class DAOImpl implements DAO {
       public static ValueObject daoMethod() {};
    }

    This can't be done.

    cheers,
    Paul

    Hello
    >
    > The Data Access Object pattern (DAO) is a well known pattern that is used with domain models, even when using Entity Beans. However, normally, the pattern involves instantiating extra objects, rather than using static methods.
    >
    > So for example, it is not unusual to have an entity bean and 2 additional objects to implement the DAO.
    >
    > 1)Why not use a class with static methods that implement the JDBC calls? Surely, in a multi-user environment, this would be advantageous for performance and scale? And as far as I can tell, the DAO generally does not encapsulate any data as such.
    >
    > 2) Equally well, the Entity bean could sure pass a reference to itself (via "this") to the static methods of the Data Access CLass. The DAO class could then populate the entity bean propoerties directly, rather than having to create a plain old java object that essentially is identical to the entity bean, and then having the entity bean copy this data to itself.
    >
    > I do realise that the Entity Bean spec prevents an entity bean from returning a reference to itself via "this", but as I described it , I do not se a problem (and it does work!)
    >
    > Can someone set me straight please?
    >
    > Confused
    >
    > Paddy
  3. performance implications?[ Go to top ]

    Thanks Paul.

    I can understand how the use of interfaces will make the design more flexible and extensible.

    But assuming for a second that I do not actually need to use an interface, and never expect the need to have different DAO implementations for differing types of databases, then let's assume that I create a plain old Java DAO Class (no interfaces) with static methods for getting/inserting etc.

    Now, if 100 processes are inserting at any one time on this particular table, I do not have the overhead of instantiating the 100 Data Access Objects.

    1)Surely, this is better for perofrmance and scale?

    2) Is there an inherent bottleneck in having a single static method servicing a large number of simultaneous requests?
  4. performance implications?[ Go to top ]

    Now, if 100 processes are inserting at any one time on this particular table, I

    > do not have the overhead of instantiating the 100 Data Access Objects.
    > 1)Surely, this is better for perofrmance and scale?
    This overhead is usually small, as DAOs usually do not have any member non-static fields. And if want to avoid that overhead, you can share the same DAO between all the processes - make an eagerly-initialized singleton.

    > 2) Is there an inherent bottleneck in having a single static method servicing a
    > large number of simultaneous requests?
    You'll get a bottleneck only if you need to synchronize inside the method. Some of those cases can be resolved easily if you can make a copy of the resource being synchronized. That will usually lead you to implementa a DAO (one DAO object per thread).
  5. Is use of a DAO pool recommended[ Go to top ]

    Hi, Instead of using a Singleton or static methods inside the DAO classes can we resort to a pooling mechanism. Is there any overhead associated with it. The DAO connections can be pulled from the pool and returned to the pool pretty similar to the Stateless Session Bean funcationality.. Rgds Shashank
  6. Interfaces for Different Databases[ Go to top ]

    One thing to bear in mind with interfaces in the DAO pattern. Not only would you use them for different databases, you may also wish to swap testing in and out with ease using a standard factory pattern to return the DAO interface. Or, you may decide to try Hibernate, or JDO, or even Entity Beans ;) Using the interface would allow you to try any of these without having to change your calling code. That's the main reason I'd be using interfaces here, not because of different databases.

    The other reply pointed out the potential of using a singleton instead of static methods, that would work and fit in with minimizing the object usage. However, I doubt that using the standard DAO pattern and the objects it creates will cause any resource issues in your system, and it makes sure that the class is not sharing any resources which may cause problems, e.g. I've seen a situation where a singleton was used, and a connection was obtained using a super class, this caused sharing problems with the connection. A bit dumb I admit, but these things can happen.

    cheers,
    Paul