> 1. Objects with 100's of attributes are a red flag for me. It suggests
the object model may need refactoring. Doing so may improve the maintenance
and performance issues you face, using EJB or not.
>
100's of attributes or a fine network of objects, either way you refactor
it, those data need to be pulled across somehow.
> 2. It is possible to avoid the object-relational mapping problem
altogether with non-relational database technology, such as that available
from Object Design or Versant. You give up SQL access to your data with
these databases, but you gain a simpler architecture and better performance
in applications where speed is critical. All the SQL queries and O-R
mapping code goes away, and you store your beans, references and all,
directly in the database.
>
Oh, certainly--GemStone/J is also great for this. The key problem here is
that (a) many projects aren't building a data store from scratch, and will
need to interact with data stores that were created even 5 years ago--all of
them RDBMSs, and (b) with an OODBMS you lose many of the
cheap-and-end-user-frieldy off-the-shelf reporting tools, such as Crystal
Reports, leaving reports to become a task the developer has to take care of.
Yuck--I'm trying to get things *off* my plate. As to the performance of an
OODBMS, *shrug* that's something that we could debate until the cows come
home.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
----- Original Message -----
From: "Thomas Groot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 15, 2002 6:05 AM
Subject: Re: [EJB-INT] As a Person Looking into EJB...
> On Mon, 14 Jan 2002 18:03:59 -0800, Ted Neward <[EMAIL PROTECTED]>
wrote:
>
> [clip]
>
> See below
>
> >
> >> It sounds like you like EJB's persistence and component model aspect.
> >>
> >> I have a few issues with EJB's persistence. In fact, the first one of
> >these
> >> problems is not even unique to EJB, but OO paradigm in general. Many
of
> >> objects has many columns of data (over 100 columns). When an
application
> >is
> >> running, the user typically works only with only a handful of these
> >columns
> >> (human beings are not equipped to deal with 100's of pieces of info all
at
> >> once).
> >>
> >> So, different applications ('modules' to be exact) work on different
> >subsets
> >> of this large number of columns. Yet, the business logic must be
> >> centralized and managed in the context of one object class (like you
> >> mentioned).
> >>
> >> The problem is that OO paradigm wants the entire object to be realized
in
> >> memory before anything happens. This causes memory usage problems,
> >> scalability problems, and performance problems. Previously, we've
> >attempted
> >> to implement 'partially initialized' object, but, like you said, this
> >ended
> >> up strewing bits of SQL in many places--maintenance problems.
> >>
> >This is the Object-Relational Impedence Mismatch summed up in three
> >paragraphs--Relations and Objects are two very different ways of viewing
the
> >world, and it's almost impossible to match the two flawlessly. Yet we
keep
> >trying to do so, because each offers unique strengths and flexibility not
> >found in the other. This is, without a doubt, one of the hardest areas of
> >objects to understand and "get right" (if such a thing is possible).
> >
>
> Two observations:
>
> 1. Objects with 100's of attributes are a red flag for me. It suggests
the object model may need refactoring. Doing so may improve the maintenance
and performance issues you face, using EJB or not.
>
> 2. It is possible to avoid the object-relational mapping problem
altogether with non-relational database technology, such as that available
from Object Design or Versant. You give up SQL access to your data with
these databases, but you gain a simpler architecture and better performance
in applications where speed is critical. All the SQL queries and O-R
mapping code goes away, and you store your beans, references and all,
directly in the database.
>
> Why use EJB? You may or may not need it. Atong, you might want to
explain your application in further detail, and get feedback on EJB's
applicability from the list. It's difficult to discuss the generic benefits
of EJB beyond what you will find on Sun's web site. A specific project
discussion would make an interesting thread!
>
> [clip]
>
>
> Tom Groot
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
