CMP and DAO...

[Erik Brakkee]

Hi,


The people who invented the pet store application and the people who write books about SCEA certification seem to believe that a DAO is not necessary when CMP is used.

This I think is rather strange since:
1. if a domain object is a CMP entity bean then it must implement the EntityBean interface, which means it is intrusive design.
2. CMR behaves differently from POJOs. For instance, removing one end of an association als removes the other automatically which is not true for POJOs. In other words, making a domain object an entity bean ties you to the entity bean.
3. a DAO can also have another function, which is to map finegrained objects
to coarse grained ones and back (Data Mapper pattern in patterns of enterprise application integration).

Also, a DAO has the advantage of being able to test outside of the container (e.g. with an inmemory implementation). In other words, I would go more for a design with DAOs as interface to persistence and CMP entity beans purely for the implementation of the DAO.

Does anyone have any experience submitting a SCEA assignment with a design like this?

Cheers
Erik

[Lokesh Rai]

Hi Erik,

Even I am using DAOs (with BMP) in most places, except in one place where I am using CMP (where update to database is done). I think for reading data (e.g. searching flights), DAO+BMP does a good job, without the overhead of expensive CMP. Having said that, with CMP 2.0, they say it has changed, i.e. CMPs give better performance.

Also, when you use DAO, I think we should make sure BMPs are used with the DAO, so that migrating to CMP later on is easier.

Lokesh

[Erik Brakkee]

Hi Lokesh,


The arguments you give are well-known. Wrapping BMP entity beans by DAOs to make it easier to migrate to CMP. Nevertheless, I am advocating the use of DAOs even with CMP. In other words, not using entity beans as 'business objects' but simply using them as an implementation of a persistence mechanism hidden behing a DAO interface.

Cheers
Erik

[Joel Schnider]

You may be right, but I don't fully understand your design.

Isn't the remote interface of my CMP the same as the DAO interface of your CMP?

Originally posted by Erik:
Hi Lokesh,


The arguments you give are well-known. Wrapping BMP entity beans by DAOs to make it easier to migrate to CMP. Nevertheless, I am advocating the use of DAOs even with CMP. In other words, not using entity beans as 'business objects' but simply using them as an implementation of a persistence mechanism hidden behing a DAO interface.

Cheers
Erik

[Erik Brakkee]

Hi,


Almost right. The home interface of my entity bean will be almost the same as the DAO interface, except that the DAO interface does not extend EJBHome.

But, although I would go for such a design in practice, to make it more J2EE independent, I will probably just go for CMP entity beans for the assignment as is to keep things simple for SUN and to increase my chances of succeeding.

Cheers
Erik

[Karimulla Shaik]

I am really not sure what benifits one gets by wrapping DAO inside a CMP Entity Bean. I belive this is a bad design practice and this approach defeats the purpose of the CMP enity bean which is provide the transparent persistence mechanism.

If at all , a better control is required over persistence mechanism , then one can use a BMP + DAO.


regards
Karim

[Roger Chung-Wee]

I am inclined to think that the DAO pattern should in general always be used. Think about why you want this pattern: it's to shield the business objects, be they EJBs or POJOs, from knowing anything about object persistence and whatever data access mechanism is needed for that persistence. Furthermore, a DAO provides a single, consistent API for data access of any kind. An example is provided below.

    public interface CustomerDAO
    {
      public void insert(Customer customer)
       throws CustomerDAOException;
 
      public void update(CustomerPK pk, Customer customer)
       throws CustomerDAOException;
 
      public void delete(CustomerPK pk)
       throws CustomerDAOException;
 
      public Customer[] findAll()
       throws CustomerDAOException;
 
      public Customer findByPrimaryKey(String email)
       throws CustomerDAOException;
 
      public Customer[] findByCompany(int companyId)
       throws CustomerDAOException;
    }

So, you may start out by implementing persistence by entity beans (CMP or BMP) but switch later to something else such as JDBC, JDO or Hibernate. You would of course have to write a new class that implements the DAO interface, but extensive re-engineering of existing code would not be required.

[Karimulla Shaik]

I agree with you that using DAO with BMP helps you to use DAO for just JDBC , JDO or Hibernate in future. But I do not understand why should one use DAO with CMP when Container already manges the persistence on its own based on the information provided in deployment descriptor.

regards
Karim

[Erik Brakkee]

Hi Roger,


You understand exactly what I mean.

As for the reasons to use wrap CMP entity beans with DAOs. There are many:

It makes your code independent on J2EE and thus also testable outside

of an application server which is a huge advantage. Also, it provides
a huge simplification of the domain model since it does not have
to deal with the intricacies of entity beans.

It decouples the development of your domain model from that of the

database. In particular you can use an assembler to map a fine grain
domain model to a coarse grain model of entity beans.

It provides more freedom in the design of your domain model. In

particular, simple things in a regular POJO domain moasidel such as
inheritance are difficult with entity beans.

I think I am going for a design with DAO + CMP for these reasons because I am using inheritance in my domain model. Looking on the internet for some tricks to see how to implement inheritance with entity beans, it is apparent that this is possible, but increases complexity, and in my opinion increases it too much.

By the way, I think there is growing consensus these days that entity beans are one of the shortcomings of J2EE. At work we are doing all new development using DAOs and Hibernate. DAO to be independent of the persistence mechanism and Hibernate for obtaining the easy mapping of a fine grain object model to a coarse grain data model, and to allow persistence also to be used outside of the container.

Doing the certification feels a bit like selling my soul, but it is possible to do a proper design with entity beans as well. If inheritance would have been easier with entity beans, then I could have simplified my submission by using CMP entity beans directly. Now because of these shortcomings, I have to introduce DAOs because otherwise the code would get too complex for my taste.

Cheers
Erik

[Roger Chung-Wee]

By the way, I think there is growing consensus these days that entity beans are one of the shortcomings of J2EE.

That consensus is apparent in the EJB 3.0 spec which defines entity beans as POJOs which model application data. Then, with a set of simple annotations, the container figures out how to map these objects into tables in relational databases.

[Erik Brakkee]

Hi Roger,

Unfortunately, I am not well versed enough on EJB 3.0 to use that one in the assignment. I am just going for EJB 2.1. I am leaving EJB 3.0 for some later time.

Off topic:
By the way, with EJB 3.0, will my entity beans be concrete classes instead of abstract? Can I test my EJB 3.0 entity beans with CMR in a standalone environment or do I still need to use a container to test them?

Cheers
Erik

[Ajith Kallambella]

Hello "Erik"-

Welcome to JavaRanch.

On your way in you may have missed that JavaRanch has a policy on display names, and yours does not comply with it - please adjust it accordingly, which you can do right here. Thanks for your prompt attention to this matter.

Enyoy your time here.