Java Reference
In-Depth Information
depend many factors, including the databases your container supports, the
complexity of your database, the quantity of non-Java clients, or the amount
of legacy code.
Entity beans can be a hard sell in many development environments. We
can see three strong reasons to resist the use of entity beans.
1.
Heterogenous environments.
In many enterprises, rich and diverse sets
of development environments exist—Windows.NET and ASP clients,
mainframe clients, C and C++ applications, third-party applications, and
Java. The solution many database environments adopt is to use stored
procedures that are shared across all of these platforms to concentrate
database access into a common set of code. Stored procedures do not tend
to be written with the kind of strict row-to-object mapping that entity
beans model so well; instead, they are often designed to support specific
business processes. That fits so well with the session bean model that you
may be tempted to implement a session bean facade in front of such stored
procedures and leave it at that.
2.
Legacy code.
A variation on the above argument exists when there is al-
ready a considerable body of code, perhaps even Java code written directly
using JDBC, that accesses the database and performs the common opera-
tions. Here again, the simplest solution is to put a session bean facade on
the already existing code.
3.
Mobile cheese.
One of the trendy business topics published recently is ti-
tled
Who Moved My Cheese?
and it is about the negative ways in which
people react to change. You might very well meet resistance simply because
the technology is new and unfamiliar, and represents a change in thinking
about data persistence from what the development staff is used to doing.
So, where is it suitable? Entity beans are particularly well suited to environ-
ments that are homogenous by being based either mostly on Java or on
CORBA/IIOP. Further, they are well suited to environments where the bulk
of the work is the editing and manipulation of small numbers of entities per
session, as opposed to large reports or statistical queries where a session might
want to use many or all rows in a table.
Please note that using entity beans in such appropriate cases in no way
precludes other types of use! You just won't likely use entity beans for them.
In other words, you don't have to use it just because it is there.
