> Interesting example. You're striking a compromise
> between a small-object hierarchy (good OO design, from
> a purist's perspective) and better performance.
> You're considering the database layer's performance in
> the design of your object model.
>
Whoa--you're saying you DON'T consider the database layer's performance in
the design of your object models?!?
> This gets to the heart of EJB's value. EJB (and CMP
> in particular) is an abstracting technology that takes
> you out of the details of managing (and persisting)
> your objects at runtime. You are free to align your
> object model with your business logic, blissfully
> ignorant of performance at runtime. Performance is
> tuned at runtime, after the beans are deployed, in a
> very similar way to an RDBMS. This is a very
> attractive idea in many corporate IT settings.
>
Oh, man, Thomas, did you just open a HUGE can of worms with this one. Ask
ANY DBA for a large SQL database how long they left the SQL written "as-is"
and were able to tune just by tweaking the SQL engine's parameters--for my
experience, the answer is "none". Blissful ignorance just leads to pain and
agony--it's only blissful in the developer's mind.
> That's the theory, anyway. Both the spec and the
> vendors add lots of features designed to give you more
> control over performance *that gets built into the
> beans*, which violates the underlying philosophy. But
> we've been violating encapsulation since the early
> days of OO, so why stop now? ;-)
>
And the reason they give this to us is because the market demands it. If the
world had wanted a pure object model, we would have stopped at Smalltalk.
> If you are comfortable ignoring most performance
> issues in your business logic, EJB will support you in
> that. You can build clean, readable, maintainable
> object hierarchies, and let the app server worry about
> performance. If you want to tweak and tune things, you
> will find your hands tied in important ways with J2EE,
> or you'll have to make the sorts of compromises you
> discuss. But that's not uncommon in software projects
> today, is it?
>
"If you are comfortable ignoring most performance issues in your business
logic, EJB will support you in that." A better reason to abandon the entire
thing I can't imagine. Case in point: if you completely ignore database
design when designing entity beans, many servers will do the simplest thing
from their perspective: Design a table with a primary key column, and a
single BLOB column holding the Serialized representations of the entity
bean. This is NOT something that tweaking the database engine will help
improve performance--only rebuilding the entire databse and porting the data
will have any effect.
I hate to make this sound like a flame, Thomas--it certainly didn't intend
to come out that way. I'm certain you are a bright guy and have your reasons
for choosing the approach you do, but it so contradicts my own agenda and
approach that I find it hard to relate. :(
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 8:44 AM
Subject: Re: [EJB-INT] As a Person Looking into EJB...
> Interesting example. You're striking a compromise
> between a small-object hierarchy (good OO design, from
> a purist's perspective) and better performance.
> You're considering the database layer's performance in
> the design of your object model.
>
> This gets to the heart of EJB's value. EJB (and CMP
> in particular) is an abstracting technology that takes
> you out of the details of managing (and persisting)
> your objects at runtime. You are free to align your
> object model with your business logic, blissfully
> ignorant of performance at runtime. Performance is
> tuned at runtime, after the beans are deployed, in a
> very similar way to an RDBMS. This is a very
> attractive idea in many corporate IT settings.
>
> That's the theory, anyway. Both the spec and the
> vendors add lots of features designed to give you more
> control over performance *that gets built into the
> beans*, which violates the underlying philosophy. But
> we've been violating encapsulation since the early
> days of OO, so why stop now? ;-)
>
> If you are comfortable ignoring most performance
> issues in your business logic, EJB will support you in
> that. You can build clean, readable, maintainable
> object hierarchies, and let the app server worry about
> performance. If you want to tweak and tune things, you
> will find your hands tied in important ways with J2EE,
> or you'll have to make the sorts of compromises you
> discuss. But that's not uncommon in software projects
> today, is it?
>
> TG
>
> --- Atong Appa <[EMAIL PROTECTED]> wrote:
> >
> > >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.
> > >
> >
> > Take an order fulfillment line info for an example.
> > It needs a few columns
> > to identify itself (which order it belongs, an id
> > for identification). You
> > need a handful of information about when/how the
> > line was created: what was
> > the quote, how the line will be fulfilled, who will
> > be responsible for
> > tracking it. You need info on the item itself
> > (description, measture,
> > quoted process, currency conversion for the line, so
> > on). Since multiple
> > lines from multiple order will be lumped together
> > for fulfillment, you need
> > info on procurement. You need about 20 columns to
> > deal with internal
> > bookkeeping issues and stored calculations (so that
> > you wouldn't have to
> > compute these values every time).
> >
> > For each of these categories, you need some
> > audit-trail: when was it last
> > updated, has there been changes, who changed it,
> > why, etc.
> >
> > You would probably assert that these should all be
> > refactored into smaller
> > objects. Theoretically, it makes a lot of sense.
> > However, when it comes to
> > performing validation and actual processing of this
> > object, separating them
> > into say 6 objects means you have to manage
> > relationships among them and
> > manage caching of these objects.
> >
> > The tradeoff one has to make is where you define the
> > object class boundary.
> > You want the object to be self-contained enough that
> > you will not thrash
> > (keep bringing objects in and out) and that you
> > would spend too much time
> > modeling and managing relationships between objects,
> > BUT want the object
> > small enough to keep it maintainable would not
> > violate data integrity model
> > (in relational speak, be reasonably normalized).
> >
> > OO tends to force you to go small objects with lots
> > of relationships which
> > works well only if the cost of relationship
> > traversing is close to zero
> > (which it isn't).
> >
> >
> > >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.
> >
> > I am somewhat familiar with object databases and (no
> > offense) would stay
> > away from them for query-intensive apps. The main
> > trouble with odbs is
> > pretty much the same problem I described re: OO
> > paradigm above. It needs to
> > realize the entire object. So, if I want to project
> > and join, etc. (which
> > are all value-based operations), it falls flat on
> > its face. If you need to
> > manipulate the data and partition processing of data
> > between client and
> > server, odbs don't perform. If your objects don't
> > need manipulations like
> > projection and join, it works well.
> >
> >
> > Atong
> >
> >
> > >
> > >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".
> > >
> >
> >
> >
> _________________________________________________________________
> > Join the world?s largest e-mail service with MSN
> > Hotmail.
> > http://www.hotmail.com
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
>
>
===========================================================================
> 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".
