EJB - Why do we need java persistence on top of a database?

[javaguy44]

Hi,

I'm new to EJB, and have done some tutorials etc. but haven't seen the
need for persistence yet.

As I understand it, making an object persistent means that the object
lives forever, even if there's a shut down of the app server. Is this
right?

Now my question is, what role does entity bean persistence play, that
a database cannot do? This is what I don't understand.

Thanks for helping a EJB newbie

 

[Michael Borgwardt]

I'm new to EJB, and have done some tutorials etc. but haven't seen the
need for persistence yet.

As I understand it, making an object persistent means that the object
lives forever, even if there's a shut down of the app server. Is this
right?

Depends on how you define "live". The data is preserved and the object
can be recreated when needed.

Now my question is, what role does entity bean persistence play, that
a database cannot do? This is what I don't understand.

It's an additional abstraction layer that achieves a number of things:
- independance from specific database products
- transparent clustering
- declarative transaction definition

 

[Fedor]

Hi,

I'm new to EJB, and have done some tutorials etc. but haven't seen the
need for persistence yet.

As I understand it, making an object persistent means that the object
lives forever, even if there's a shut down of the app server. Is this
right?

Now my question is, what role does entity bean persistence play, that
a database cannot do? This is what I don't understand.

People always start talking about 'transactions'... Ask
them what a transaction actually is; that's quite funny

EJB is a hype consisting of some over-engineered frameworks.

Use plain sockets for communication and plain sql for persistancy.
That's much cleaner. This kind of stuff seems to be hard for
average programmers, so they invented all this EJB-crap and
made some wizards in WSAD......

Have you ever seen a real working EJB-application? Does amazon,
google, hotmail use them? I don't tink so... Is it necessary?
I don't think so....
When EJB is involved a project it 's all about adding more
hardware because performance is bad.



Fedor

 

[Michael Borgwardt]

Use plain sockets for communication and plain sql for persistancy.
That's much cleaner. This kind of stuff seems to be hard for
average programmers, so they invented all this EJB-crap and
made some wizards in WSAD......

Use plain assembler for programs, the "ed" editor to write the code.
That's much cleaner, but it seems to be hard for average programmers,
so they invented all this high-level language crap and made decadent
resource-wasting editors live vi.

Have you ever seen a real working EJB-application? Does amazon,
google, hotmail use them? I don't tink so... Is it necessary?
I don't think so....

Nice demonstration of the "argument by baseless assertion" technique there...

 

[Fedor]

It's an additional abstraction layer that achieves a number of things:
- independance from specific database products

ANSI-SQL is database independent as well, and JDBC wraps
low-level interfaces to relational databases. If you ever have to
change SQL, because use want to use a new database (have you
ever seen a project where they switched to another DBMS?),
it's always less work than change your EJB-code to conform
a new EJB-standard used in a new version of the appserver, that
you have to use because the old one contains memory leaks,
and security bugs.

- transparent clustering

Most of the time you have to buy more hardware because of the
overhead of EJB. Processors are fast enough to calculate a
game off chess 10 ply deep.
999 out of 1000 projects need clustering. If you write efficient
code, there is no need to cluster. And still, there is no need
to use EJB as long as sessions are serializable and your app-server
supports cloning, you can do load balancing.

- declarative transaction definition

transaction? what's that?

Isn't a transaction an application level issue? Isn't that
'business logic'? And with JDBC you can just do rollback().
'declarative transactions' on the application level can
be implemented using;

if (enoughCredits)
execute();
else
rollBack();


Fedor.

 

[Fedor]

Use plain assembler for programs, the "ed" editor to write the code.
That's much cleaner, but it seems to be hard for average programmers,
so they invented all this high-level language crap and made decadent
resource-wasting editors live vi.

Assembly language not platform independent and therefor it could
be evil. EJB is even more evil, because it's EJB-spec-version-dependent.



Fedor.

 

[Ryan Stewart]

ANSI-SQL is database independent as well, and JDBC wraps
low-level interfaces to relational databases. If you ever have to
change SQL, because use want to use a new database (have you
ever seen a project where they switched to another DBMS?),

Yes, several in the past year.

it's always less work than change your EJB-code to conform
a new EJB-standard used in a new version of the appserver, that
you have to use because the old one contains memory leaks,
and security bugs.

I don't use EJB's, but using any of the persistence methods we use is *many*
times easier and less work than managing SQL statements.

Most of the time you have to buy more hardware because of the
overhead of EJB. Processors are fast enough to calculate a
game off chess 10 ply deep.
999 out of 1000 projects need clustering. If you write efficient
code, there is no need to cluster. And still, there is no need
to use EJB as long as sessions are serializable and your app-server
supports cloning, you can do load balancing.

So don't use EJB's if your application doesn't need them, but use some
persistence mechanism.

transaction? what's that?

A unit of interaction with the database which is all or none. It usually
consists of multiple updates (not in the SQL sense) to a database that must
be done as a unit to keep the database in a valid state. No changes are made
to the database until the entire transaction is complete. If any of the
updates fail, the transaction is rolled back so that none of them are
carried out. If all are successful, the transaction is committed, and the
changes are actually made.

Isn't a transaction an application level issue? Isn't that
'business logic'?

Not necessarily.

And with JDBC you can just do rollback().
'declarative transactions' on the application level can
be implemented using;

if (enoughCredits)
execute();
else
rollBack();

What's your point? Any good persistence mechanism will allow this if you
really need it. I've never had reason to investigate EJBs myself, but
advising someone to use JDBC when you don't know his/her situation is bad.
JDBC is suitable only for the simplest applications and should still be used
in conjunction with some design pattern that will separate the database code
from the business logic. For anything besides very basic applications, look
into an object to relational architecture like TopLink, OJB, Hibernate, etc.

 

[John C. Bollinger]

Isn't a transaction an application level issue? Isn't that
'business logic'? And with JDBC you can just do rollback().
'declarative transactions' on the application level can
be implemented using;

if (enoughCredits)
execute();
else
rollBack();

A J2EE transaction may involve manipulation of many resources, including
one or many databases, business objects, and a few other things. J2EE
transactions provide a configurable level of isolation of seperate
concurrent transactions, and support for rolling back the whole thing.
The are much broader in scope than plain database transactions. J2EE
also provides for (but does not require) "container managed
transactions", which can significantly ease the burden of supporting
transactionality in a J2EE application.


John Bollinger
(e-mail address removed)

 

[Roedy Green]

Now my question is, what role does entity bean persistence play, that
a database cannot do? This is what I don't understand.

See http://mindprod.com/jgloss/pod.html

The persistent object model allows for complex connections between
objects. Before you can use an SQL database for persistence, you have
to figure out how to store everything in tables.

PODs store complete objects. SQL stores fields.

 

[Fedor]

See http://mindprod.com/jgloss/pod.html

The persistent object model allows for complex connections between
objects. Before you can use an SQL database for persistence, you have
to figure out how to store everything in tables.

PODs store complete objects. SQL stores fields.

The objects living in java are the same as the objects living
in the database. A relational database is much more powerfull
and - in my opinion - usefull to exploit it's functionality.

A relational database is just a complex datastructure
which is able to manage large amounts of data. On top
of that you build a java-application in which you have
different objects, not copies of the database tabels!

For instance; in the database you have a table containing
customer data, an other table contains product information,
an you have tables containing orders and order lines.

Now, you can build a java application for planning
the routes of truck drivers and the way the truck should
be loaded. You're getting nowhere with object-persistance
stuff? You don't even want orderline, orders, customers
and products in your java-app. Your business logic on
the application level is implemented in java classes
like 'route', 'delivery' etc... These objects are constructed
by doing intelligent SQL-queries which cannot be generated
by frameworks.

I think this discussion is about developing an application
by starting with a relational database (which based on
mathematical rules) vs. starting with some object-model
(which is based on some recent software engineering 'theory').

Am I wrong here?

 

[Ryan Stewart]

The objects living in java are the same as the objects living
in the database. A relational database is much more powerfull
and - in my opinion - usefull to exploit it's functionality.

Objects in Java and "objects" in a database are not at all the same. You
might call them entities, but not objects. Databases support object oriented
design in limited, primitive ways only. And a database is more powerful and
useful than what? Java? Only at the task it was designed for: data
management.

A relational database is just a complex datastructure
which is able to manage large amounts of data. On top
of that you build a java-application in which you have
different objects, not copies of the database tabels!

You don't build an application on a database. You design a database to back
an application. Objects are not quite copies of tables, but there should be
a strong resemblance.

For instance; in the database you have a table containing
customer data, an other table contains product information,
an you have tables containing orders and order lines.

Now, you can build a java application for planning
the routes of truck drivers and the way the truck should
be loaded. You're getting nowhere with object-persistance
stuff? You don't even want orderline, orders, customers
and products in your java-app.

Wrong on several counts. If orderline, orders, customers, and products are
central to your application, then you want them represented as objects.

Your business logic on
the application level is implemented in java classes
like 'route', 'delivery' etc...

It's fine that (most of) your business object is implemented elsewhere, but
the way you describe, it would be intertwined with your database, which is
bad.

These objects are constructed
by doing intelligent SQL-queries which cannot be generated
by frameworks.

Even ignoring what I've already said, this is pure rubbish. You need to do
some research before you make such assertions. If anything, a good
persistence framework allows you to write extremely complex queries much
more easily than with pure SQL. That's besides the fact that frameworks are
much faster than SQL because of object caching.

I think this discussion is about developing an application
by starting with a relational database (which based on
mathematical rules) vs. starting with some object-model
(which is based on some recent software engineering 'theory').

Am I wrong here?

Perhaps not, for maybe the first time in this post. But if you're suggesting
that application design should begin by designing a database, I have to
disagree. If you're suggesting that a database is based on rules and an
object model is not, I have to disagree again. And if you're suggesting that
a database is capable of replacing an object model, I have to laugh in your
face. Trying to design from the database to an object model will lead you to
coerce objects into unnatural uses and states, or at best, to use only
simple objects as data representations. Designing an object model to
accomplish your task and backing it by a database leaves you open to using
the full power of Java as an object-oriented language, which is where its
power lies. I've seen projects wilt and die because too much work is done
directly from the database rather than using objects to manage and act on
the data.

 

[Bryce]

ANSI-SQL is database independent as well, and JDBC wraps
low-level interfaces to relational databases. If you ever have to
change SQL, because use want to use a new database (have you
ever seen a project where they switched to another DBMS?),

Actually... Yes. Many times.

 

[Fedor]

Objects in Java and "objects" in a database are not at all the same. You
might call them entities, but not objects. Databases support object oriented
design in limited, primitive ways only. And a database is more powerful and
useful than what? Java? Only at the task it was designed for: data
management.

Entities, objects, whatever...it's just a matter of definition.
Call a table a class and call a record an instance. The only
difference is behavior (methods) which is embedded in an object.
Behavior persistance is nonsense and there is no need to store
it in a relational database, because the only relation the
behavior has is a relation with the object it belongs too.
Perhaps state is important to store, or is it not? State is
just a matter of values in data members.

Relational database fully support object oriented design. Object
oriented languages do not. In a java class you have a lot
of references to other objects, like a class called Person
with to strings in it; name and address.
How do you know in advance if you want one class called
'Person' or two classes: 'String' and 'Person'. What's the
relation between them? Or is there no relation and should
we just design it as one class? There is always a matter
of 'common sense' when designing such stuff. A java
class typically has many relations with other classes.
Almost each datamember is a relation with another
class.

When you just focus on data, you don't have these
problems. You don't have to group data in classes.
You can classify the data by firing SQL-queries on
your tables. That's very powerfull and (when setup
correctly) also very fast.

You don't build an application on a database. You design a database to back
an application. Objects are not quite copies of tables, but there should be
a strong resemblance.

That's just my point. Since OO, people started to abuse
relational databases for this purpose. It's a new way
of desiging applications. In my opinion a properly designed
database in which data cannot be corrupted (in terms
of application logic) should be the core of an application.
On top of it, you can build anything you like.

If you have a database with customers, orders, orderlines
and products you can create applications for:

- planning routes for delivery of goods
- marketing purposes
- an online ordering system for customers
- a planning system for the busy days around christmas

etc.

If you design in the OO way and use the relational
database just for object persistancy, the database
will be bloated at the end.

Wrong on several counts. If orderline, orders, customers, and products are
central to your application, then you want them represented as objects.

I do not agree. Truck drivers have nothing to do with customers,
orders, and orderlines. They only want to know about adresses and
boxes with goodies. These objects live in the application for the
truck drivers and is build around an existing database used
for making orders.

It's fine that (most of) your business object is implemented elsewhere, but
the way you describe, it would be intertwined with your database, which is
bad.

Why is that bad?
Is it bad when I have fine grained data in my database and
some more raw objects in my application? That's just the power
of a relational system...with intelligent SQL queries you can
any dataset (read: object) you like.

Even ignoring what I've already said, this is pure rubbish. You need to do
some research before you make such assertions. If anything, a good
persistence framework allows you to write extremely complex queries much
more easily than with pure SQL. That's besides the fact that frameworks are
much faster than SQL because of object caching.

Because of object caching? A query generated by a persistance framework
can't be more efficient than a hand crated query, just because it's
more high level.

Perhaps not, for maybe the first time in this post. But if you're suggesting
that application design should begin by designing a database, I have to
disagree. If you're suggesting that a database is based on rules and an
object model is not, I have to disagree again. And if you're suggesting that

In my opinion a database is the perfect place for implementing
business logic!

a database is capable of replacing an object model, I have to laugh in your
face. Trying to design from the database to an object model will lead you to
coerce objects into unnatural uses and states, or at best, to use only
simple objects as data representations. Designing an object model to
accomplish your task and backing it by a database leaves you open to using
the full power of Java as an object-oriented language, which is where its
power lies. I've seen projects wilt and die because too much work is done
directly from the database rather than using objects to manage and act on
the data.

But what's an object in your opinion? don't you mean a 'class'?


Fedor

 

[Ryan Stewart]

Entities, objects, whatever...it's just a matter of definition.
Call a table a class and call a record an instance. The only
difference is behavior (methods) which is embedded in an object.
Behavior persistance is nonsense and there is no need to store
it in a relational database, because the only relation the
behavior has is a relation with the object it belongs too.
Perhaps state is important to store, or is it not? State is
just a matter of values in data members.

Granted, but that's the point. Databases are for storing data, not for being
an object model.

Relational database fully support object oriented design. Object
oriented languages do not.

That's absurd. How do you support this statement?

In a java class you have a lot
of references to other objects, like a class called Person
with to strings in it; name and address.

Name might not be a String, and address certainly wouldn't be.

How do you know in advance if you want one class called
'Person' or two classes: 'String' and 'Person'. What's the
relation between them?

Not following you here.

Or is there no relation and should
we just design it as one class?

Design what as one class?

There is always a matter
of 'common sense' when designing such stuff. A java
class typically has many relations with other classes.
Almost each datamember is a relation with another
class.

Of course you have to use common sense. It's also beneficial to follow
certain standards. I wouldn't agree that most data members are relations to
other classes, though.

When you just focus on data, you don't have these
problems.

Your "problems" made no sense to me.

You don't have to group data in classes.

You never *have* to group data in classes. But most sane people *want* to.

You can classify the data by firing SQL-queries on
your tables. That's very powerfull and (when setup
correctly) also very fast.

As fast as accessing local memory? Sorry, not possible except *possibly* if
your database is also local: an improbable scenario for anything but a tiny
enterprise system. And please tell me you at least use connection pooling
when you're doing all this SQL stuff.

That's just my point. Since OO, people started to abuse
relational databases for this purpose.

Abuse? What purpose?

It's a new way
of desiging applications. In my opinion a properly designed
database in which data cannot be corrupted (in terms
of application logic) should be the core of an application.
On top of it, you can build anything you like.

Absolutely. OOD doesn't dictate a badly designed database. But a database is
not the "core of an application". It's the data store of an application. An
application can run fine without a database. It would just have a short
memory.

If you have a database with customers, orders, orderlines
and products you can create applications for:

- planning routes for delivery of goods
- marketing purposes
- an online ordering system for customers
- a planning system for the busy days around christmas

etc.

If you design in the OO way and use the relational
database just for object persistancy, the database
will be bloated at the end.

False in my experience. On what grounds do you base this statement? Besides,
the database isn't necessarily about object persistence. It's about data
persistence.

I do not agree. Truck drivers have nothing to do with customers,
orders, and orderlines. They only want to know about adresses and
boxes with goodies. These objects live in the application for the
truck drivers and is build around an existing database used
for making orders.

You're blurring the lines here. If the application is for calculating
trucking routes, then what do customers and products have to do with it?
Even orders would be stretching it I think. This data would obviously have
to be processed somewhere and handed off to your application in some form.
On the other hand, though, I have to disagree with your statement that truck
drivers have nothing to do with customers or orders (still not sure what you
mean by orderlines: it's vague). What is the driver ultimately carrying?
Orders. And where is he taking them? To customers.
but
I meant "business logic" there.

Why is that bad?

Primarily because it's generally accepted that business logic should all be
in one place, and that place is not a database.

Is it bad when I have fine grained data in my database and
some more raw objects in my application? That's just the power
of a relational system...with intelligent SQL queries you can
any dataset (read: object) you like.

Data is data. Make it as fine or coarse as you like. What does that have to
do with anything? And what is a "raw object"?

Because of object caching? A query generated by a persistance framework
can't be more efficient than a hand crated query, just because it's
more high level.

Maybe, maybe not. Have you tested that? Besides, the issue is not whether
the framework generates more or less efficient queries. The issue is that
a framework generates less queries than directly accessing the database any
time data is needed. It's the queries themselves that are expensive.

that

In my opinion a database is the perfect place for implementing
business logic!

You must have a different definition of business logic. You can't
"implement" business logic with a database, except maybe in limited ways.
Business logic is basically the code that makes the application do something
useful.

But what's an object in your opinion? don't you mean a 'class'?

No. A class is a template for creating an object. By "object", I mean an
object from an object-oriented point of view. In this case, I'm specifically
talking about a Java object. Objects are essentially where you implement
your application's business logic. Good OOD leads to clean, easily
maintainable code and logic intuitive to others versed in it. From reading
your most recent post, you seem to be confused on the purpose of EJB.
They're not something that would replace a database. They're something that
would use a database to store their state like a persistence framework does
for normal objects.

 

[Roedy Green]

you have that backwards. There is no inheritance, no references etc
etc in SQL. You do have persistence.

 

[Sudsy]

Ryan Stewart wrote:

Primarily because it's generally accepted that business logic should all be
in one place, and that place is not a database.

You must have a different definition of business logic. You can't
"implement" business logic with a database, except maybe in limited ways.

</snip>

These two comments illuminate a culture clash: the database vendors want
you to implement business logic via stored procedures (and/or triggers)
in the database engine. Sun wants to move it into the J2EE tier through
the use of session EJBs.
I subscribe to the latter approach. I want to be able to replace my J2EE
engine or my database engine as situations dictate. I don't want to be
tied to PL/SQL or any other proprietary access method.
That's also why I'm keen on entity EJBs. It's an additional layer of
abstraction which enhances both portability and scalability.
So I'm on your side, Ryan.
YMMV

 

[Fedor]

you have that backwards. There is no inheritance, no references etc
etc in SQL. You do have persistence.

I was talking about relationships between objects. In
a database you have foreing keys, but what does java offer?
It only offers datamembers, but on the other side, each
real-life Java class contains hundreds of relations with
other classes...Strings as datamembers, HashMaps for book
keeping etc.

If you're starting to design a system using class diagrams
it's much more easier to implement it in a relational
database. A class diagram is a description showing
relations, between 'things' containing data and functions.
Only functions are missing in a relational database
(perhaps you can implement them with stored procedures
and some coding conventions).

When you try to implement the same class diagram
in a language like Java, it'll result in a bunch
of struct-classes containing just datamembers and
getters and setters. I always see that in projects.
In a lot of projects this approach seems not that
practical. For example, if you designed some class
diagram with a Person, an Insurance and everything
works fine and the customer wants insurances for
animals which do have a relation with an Insurance
but with a Person too... it surely creates bloat.

Perhaps people start adding a class Animal and
a class Human which inherit stuff from an
InsuredThing-class. Others invent an InsuranceType
-class and rename the Person-class to Thing...etc...
there are a lot of options and when requirements change
you have to adapt a lot of code.

In a relational database it may be easier, but sometimes
more difficult to adapt the design. I'm not a
relational database-evangelist. My only point is
that you have to push these kinds of fundamental
business logic (not rules) to a lower level; the
database. When things need to be changed, the only
thing you have to change is an SQL-query.
If you have a table X in the database, this doesn't mean
that you have to program a class called X. That 's
just overhead. In case of the Person-Insurance-Animal
thing an application would do with a class like;

InsuranceOverview
{
public InsuranceOverview(int customerID)
{
// some jdbc-stuff
// and a simple query to join
// all tables you need

// some stuff to initialize datamembers
}
public boolean load(int customerID)
{//
}
public boolean sendBill(int month)
{//
}
}


With basic OO-theory and 'good practice' EJB-programming
you just cannot write elegant code like this


fedor

 

[Chris Smith]

I was talking about relationships between objects. In
a database you have foreing keys, but what does java offer?

Java's object model is at least as capable as foreign keys, if that's
what you mean. You can implement any data in a relational model, or in
Java's object model... but it will be far easier to understand in a Java
object model.

That's only natural. The relational model is an attempt to coerce real-
world concepts into a mathematical concept so that data can be expressed
in a canonical way that's not too dependent on the way it's used by the
application, and so that optimizations can be applied to retrieve
arbitrary sets of data quickly. And those are important requirements,
but they are necessarily abstracted from the application...
intentionally. The Java object model, on the other hand, is designed to
build abstractions of real-world concepts within a problem domain (that
is, in a way that's convenient for the kind of work that's going to be
done).

Naturally, it's far easier to design using Java objects (which are
intended for that purpose), and then figure out how that maps to your
universal data model in the database after the fact. As for the
database side, it can sometimes be very important to design correctly
from scratch there, too, if the database will be shared by a number of
software systems with different tasks and goals; but if the database
will be private to the application, it's often best to just let an O/R
mapper or EJB container generate a schema for you, and tune from there.

If you're starting to design a system using class diagrams
it's much more easier to implement it in a relational
database.

Well, no it's not. I don't know what else to say. A class diagram is
used specifically because it keeps common concerns together; everything
relevant about a type of object in a software system and its
relationships to other objects (within the context of the diagram
itself) is described on that diagram. You simply can't express that
using a relational database design tool (such as, say, an ERD).

*After* you know how the core software architecture is going to work,
then the task is to discover which small *subset* of your software
design is relevant to persistence, and design that in. In a typical
software system, far more classes will be transient than persistent, and
some classes may be relevant to persistence in some ways, but also have
transient aspects to them.

When you try to implement the same class diagram
in a language like Java, it'll result in a bunch
of struct-classes containing just datamembers and
getters and setters. I always see that in projects.

Perhaps you work on the wrong projects, or perhaps your projects are
designed by people who don't understand software architecture and think
that UML class diagrams are equivalent to ERDs. Unfortunately, UML
diagrams can only help good designers communicate their designs; no
diagramming technique can cause bad designers to produce good design.
Starting with ERDs, though, can only make it harder for software
designers to communicate designs of dynamic software... unless the only
point of the software is to create, store, and retrieve data from
database tables; and how often is that the case?

In a lot of projects this approach seems not that
practical. For example, if you designed some class
diagram with a Person, an Insurance and everything
works fine and the customer wants insurances for
animals which do have a relation with an Insurance
but with a Person too... it surely creates bloat.

Surely, the correct approach would be to use inheritance to define
several types of insurance, each type of which would know what it
applies to. Otherwise, you end up with something silly like keeping
track of the address for the property that's covered by a life insurance
policy. How to store this in the database is another matter, but the
correct abstraction is basically obvious.

Perhaps people start adding a class Animal and
a class Human which inherit stuff from an
InsuredThing-class.

I'm pretty sure no competent OO designer would ever inherit a class
called "Person" from a class called "InsuredThing". That's just dumb.

there are a lot of options and when requirements change
you have to adapt a lot of code.
[...]

When things need to be changed, the only
thing you have to change is an SQL-query.

Java and SQL are both languages. In either case, you have to update
code when the means of representing data has changed. It's quite
unlikely that only one SQL query would need to be changed. In fact,
unless the application is particularly trivial, you'll probably end up
updating some code in Java that generates SQL queries to run against the
database. You can do that yourself, or you can let an O/R mapper such
as EJB-CMP (or Hibernate or some JDO implementation or whatever) do it
for you. That's up to you, but don't make it sound so trivial. It only
is if your application is trivial.

If you have a table X in the database, this doesn't mean
that you have to program a class called X.

Of course not. It's certainly important to remember that applications
only need to deal with potentially simplified subsets of data from a
cross-application database. (If the database is application-private,
then you probably just generated a schema from your code anyway so the
question is moot.)

However, neither can you ignore the data complexity at the application
level. That application is probably responsible for a good bit of logic
that depends on various details of the data, and needs to present that
to the user. Your creation of a class with a few methods in it is a
little oversimplifying.

With basic OO-theory and 'good practice' EJB-programming
you just cannot write elegant code like this

I won't speak for the EJB environment (which is rather restrictive in
terms of what can be done), but you certainly can write far more elegant
(and what's more, functional) code than that.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation