Can I implement INSERTs and DELETEs in DAOs or only in EntityBeans?

[Tobias Merler]

Ok, when I access SQL databases I could use DAOs and EntityBeans in general.

SELECT queries can be implemented in DAOs as well as in EntityBeans.
But what about INSERTs, DELETEs and UPDATEs ?
From what I have heard so far these non-select statement MUST be implemented by EntityBeans.
Is this true?

Tobias

 

[Sudsy]

Ok, when I access SQL databases I could use DAOs and EntityBeans in general.

SELECT queries can be implemented in DAOs as well as in EntityBeans.
But what about INSERTs, DELETEs and UPDATEs ?
From what I have heard so far these non-select statement MUST be implemented by EntityBeans.
Is this true?

Not at all! I've implemented solutions using stateless session beans
which manipulate the database in the usual CRUD way. Some customers
don't want to deal with the added complexity of entity beans. In some
situations (mostly in the past) there was also a performance penalty
to pay for the additional level of indirection. Since you're using
DAOs anyway, including the additional functionality there would achieve
the same goal. You will have to manage transactions programmatically
(using JTA) rather than declaratively, however.

 

[jlp]

Ok, when I access SQL databases I could use DAOs and EntityBeans in general.

SELECT queries can be implemented in DAOs as well as in EntityBeans.
But what about INSERTs, DELETEs and UPDATEs ?
From what I have heard so far these non-select statement MUST be implemented by EntityBeans.
Is this true?

Tobias

It's false.
You can do update/delate/insert statement with POJO objects and JDBC
drivers ( POJO Plain Old Java Object ).
See also software Object/Relational Mapping like Hibernate, Cayenne,
Toplink ...
You can also use JDO to acces database.
All this software need a JDBC Driver.

 

[Oscar kind]

Ok, when I access SQL databases I could use DAOs and EntityBeans in general.

SELECT queries can be implemented in DAOs as well as in EntityBeans.
But what about INSERTs, DELETEs and UPDATEs ?
From what I have heard so far these non-select statement MUST be implemented by EntityBeans.
Is this true?

No. It depends on your design.

For best modularization, implement all database access in one layer. In
your case that would be the EntityBeans.

Another approach would be to use a library as Hibernate or a JDO
implementation for the database access.

Note however, that in both cases all database access is located in the
same layer. If you spread the database access over both DAO's (select) and
EntityBeans (the rest), your code:
- has much more dependencies
- is harder to maintain
- is not bug-prone

 

[Andrew Tyson]

DAOs anyway, including the additional functionality there would achieve
the same goal. You will have to manage transactions programmatically
(using JTA) rather than declaratively, however.

<snip>

Why is that ? We have Stateless Session EJB components that use DAOs
that implement JDBC for updates and inserts, however the container
demarcates the trx. As long as your using a pooled connection that
can participate in the container managed trx this is a perfectly valid
approach.

Regards,
AT

 

[John Fereira]

(e-mail address removed) (Tobias Merler) wrote in

Ok, when I access SQL databases I could use DAOs and EntityBeans in
general.

SELECT queries can be implemented in DAOs as well as in EntityBeans.
But what about INSERTs, DELETEs and UPDATEs ?
From what I have heard so far these non-select statement MUST be
implemented by EntityBeans. Is this true?

Generally DAO's are an interface and you provide an implementation for them.
If you don't have method signatures defined in the interface for non-select
operation you don't need to provide an implementation. Take a look at the
JPetstore example in the SpringFramework to see a good example of how DAO's,
DTOs, an object relational system (iBatis) and dependency injection all work
together.

 

[Brad]

There are two types of Entity Beans:

1. Bean Managed Persistence (BMP)
2. Container Managed Persistence (CMP)

As you probably know, an Entity Bean represents some persistent data as well
as its behaviour.

The difference between BMP beans and CMP beans is that BMP beans you the
developper must manage the behaviour of the bean where as in CMP beans you
let the container do all the work for you and you implement nothing.

So the only time YOU must implement UPDATE, INSERT, DELETE is when you have
a BMP entity bean. If you have a CMP entity bean, then this is all done for
you automatically by the container.

In any case, you can implement a DAO with your UPDATE, INSERT, DELETE calls
without a problem. If you are doing so, you do not need an Entity bean at
all.

And just to note, it has been my experience that if you are only using an
Entity bean to make SELECT calls, then use a DOA with SELECT statements
instead for performace reasons. Entity Beans should only be used to update
data because of all the overhead.

Cheers
B