well, here's my 2cts:
I have been dealing with objects and relational databases for 7 years now,
spending 4 of those writing an object-relational mapping tool for the
Smalltalk language.
I remember well the time when a CORBA persistence service and OODBMS
integration was under consideration and later abandoned because it was too
complex and ill-designed (dont know if they have come up with another one
since then). One point in the discussion at that time was that incarnating
every object in a (usually complex) persistent object model as a remote
entity would impose an unacceptable overhead and not provide any significant
benefits.
Considering my experience, I would always first opt for session beans to
implement transaction demarcation and business processes, and do the
database access either directly or through some nice mapping tool (those are
rare, however).
Entity EJBs come in handy if you really need remote accessibility, and maybe
the deferred mapping (at deployment time, meaning the deployer can choose
the persistent represenation) for CMP beans may also be an argument.
-----Original Message-----
From: bradley mclain <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Date: Dienstag, 10. Oktober 2000 17:59
Subject: RE: EJB vs Servlets
>hello all,
>
>since it came up, this is an issue that i and our
>other programmer have been wrestling with for a while,
>because like everyone else we feel the pressure to use
>the cool new stuff..and we wonder if the transactional
>and distributed advantages will help us out.
>
>here is my problem. call me dense, but i just don't
>see or mapping being as flexible as i need it to be.
>in all the books the examples tell you that you map
>your object to the table that holds its data. sounds
>fine in theory, but we have some very complex objects,
>and we have a complex relational model, the reason for
>which is to store our data efficiently, not only for
>this application, but also for others. so we have
>objects that need to get their data from different
>tables, even different databases. these objects
>contain collections, single entities, indexes into
>other objects, etc., all of which must be persisted in
>the db. we have solved the problem by writing our own
>dblayer, employing reflection and stashing all our
>queries (as well as caching them and the connections)
>in a static lookup object. this gives us a level of
>control over the data that i cannot see us getting
>from any OR tool, no matter how smart (and remember,
>the smarter something is, the slower).
>
>as to transactional support, we use jts or the db
>transaction services. no problems..
>
>as to servlets, we use exactly one per application,
>mereley to take the requests and to control
>everything--everything else is plain old java classes.
> it is blazingly fast. i cannot believe that looking
>up objects through jndi is going to be as quick as
>looking up my classes in a hashmap.
>
>if i want distribution, i simply break my app into
>multiple apps, run them on separate machines, and use
>the same object model--thats one benefit of oo, right?
>
>i hope someone has the time to refute me completely,
>because, like kevin, i really do want to understand
>what ejb will give me that i cannot live without. my
>greatest concern, as i mentioned above, is OR mapping.
> i have been a dba and a programmer, and i find it
>really difficult to believe that some tool is going to
>produce more efficient and more flexible access to my
>data than i can, given that i currently have full
>control from table to view to sp to accessor methods
>on objects..
>
>bradley mclain
>--usmoving.com
>
