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".
