I'm fairly new to EJB and have been reading the archives to help jump start my
journey. I came across an interesting thread that I had a couple of more questions
on. In particular, the post from Ian McCallion regarding a proposed "strategy" for
using EJB:
>Here's a proposed "strategy" in outline:
>2. overlay it[your DOM] with "components", Components are coarse-grained,
>independently deployable, distributable locales for application code and
>will correspont to EJBs when we come to write the actual code.
By saying "application code" (and later in the post "some logic can be...on the
server...some on the client) are you referring to Session Beans? The orginal question
was asking for a strategy for implementing domain objects as Entity Beans.
>Component will not always enclose complete DOM objects. (so that some logic for an
>object can
>be placed on the client, and other logic for the same object on the
>server).
In my case, all DOM objects will be stored in a database. In order to prevent
creating an Entity Bean for every single DOM object, you're saying that I should group
DOM objects into Entity Beans (with more than one DOM object per EB), correct? If so,
I don't see how these can overlap. If they did, I would think I would run into a
concurrency issue when two overlapping Entity Beans need the same DOM object (and
therefore database record).
Thanks,
Tim Pedone
Jostens Learning Corp
[EMAIL PROTECTED]
===========================================================================
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".
