At 07:10 22.11.00 , you wrote:
>I can see why you would want the tool to map a relational schema onto entity
>beans and dependent objects, but I don't think you really want to make every
>row in a database into an entity bean. The application won't scale well
>this way.
that is correct although there are possible reasons where you would still
do it.
1) when performance/scalability is not critical. there are cases where the
number of concurrent users and the number of records in the database allow
that approach and ejb gives you a good packaging scheme, declarative
transaction mgt, security etc. and in that case to have a generated api of
entity beans that makes use of foreign-key relationships for inter-ejb
relations is a huge time saver. best example is a content management system
used by a handful of administrators for a heavy traffic website. probably
90% of the work is implementing the administration backend which is not
critical because of a low number of concurrent requests. entity beans work
well there. for the frontend that gets all the traffic you can still
optimize a handful of operations tweaking SQL or build specialized caches.
2) for write operations on single entities the overhead is not that bad
for many application scenarios
I'm saying this because we use that approach, allthough we don't generate
the entity beans from the tables but generate entity beans and tables from
a model specified in xml. the usual approach for our web projects is
- throw the generator at the model
- see where bottlenecks are
- write specialized optimized access functionality (probably using jdbc in
session beans) for critical sections or employ application level caches at
the hot spots (e.g. cache assembled html or xml documents)
for several larger real world projects we have found that using the
generated entity bean layer is fast enough for about 90% of the
application, provided your cmp engine is well optimized (hate to say it but
so far we've been using orion, which is very good at that).
so, what many people say, that this has limitations in scalability
(probably won't be able to build amazon.com that way) is true but it's
oversimplifying to say there are no areas where this approach is good in
real world practice or that those areas are not ejb-typical. ejb != 1000
transactions per second type of applications.
regards,
robert
>Cheers
>
>-----Original Message-----
>From: Jon Finanger [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, November 22, 2000 3:53 AM
>To: jBoss
>Subject: [jBoss-User] Any R-O tool's out there?
>
>
>Hi!
>I know creating one has been up to discussion here before, but does anyone
>knows of good existing R-O tools out there (BMP)? I know there are some, but
>yet without automatic generation of entitybeans based on database metadata.
>Its a kind of tedious work to manually make hundreds of tables into
>entitybeans. :)
>
>Any reccomondation appreciated!
>
>/Jon
>
>(we should maybe consider starting such a R-O project based on the existing
>ejbdoclet...??)
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Problems?: [EMAIL PROTECTED]
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Problems?: [EMAIL PROTECTED]
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
