Robert Kr�ger wrote:
> > I would say that any data model that has 100 domain objects with no
> > independent subsets is going to be a development and maintenance nightmare
> > no matter how it's deployed. We have a similar number of domain objects but
>
> have to disagree here since we cope very well with code generation and a good
> build system based on ant always having keeping everything in sync (db-model,
> EJBs, deployment descriptors and lots more of related code) and the
> deployment organization also works without any tedious side effects.
This really has nothing to do with code generation or build systems. It has to do
with the limited capacity of most human developers. (I'm leaving room for some
super-human ones here so put yourself in the category if it applies.) If every
object is intimately connected to every other object, how can anyone a assimilate
the constant changes the must ripple through the system?
>
> > IMHO having a set of components that all have to be deployed together in
> > order to work isn't much of a component model. Limiting local relationships
> > to one ejb-jar is a good thing since it'll force developers to build better
> > components. But then we're a pretty pig head bunch :)
>
> Well, of course there are different methodologies but I disagree with the
> assessment that forcing this approach onto people (which of course we could
> also automate with our code generation tool) is the job of the spec. Also, I
> hardly ever came accross data models where you would not frequently cross
> subset boundaries (of course you draw the boundaries to minimize this but you
> still cross them). lets take a very common simplified example. many ecommerce
> systems separate stuff into subsets like catalog (items, hierarchies etc.),
> administration (customers, users, companies, access-policies) and
> transactions (orders, orderline-items, payment methods). Why would it be bad
> design to model the order that is being prepared as an ejb that has a CMP
> relationship to the customer and order line items having relationships to the
> catalogue items (of course excluding the problem of archiving orders of items
> no longer in the system, this is just an example for crossing subset
> boundaries)?
All of the relationships you mention can be modeled at the component level
without a hardwired CMP relationship. There should be a well defined interface to
customers that can be exposed via a remote interface. No need for local
interfaces and no need to put customer beans and order beans in the same ejb-jar.
If you need to exchange local interfaces between all the entity beans, then there
should be no problem putting them into one ejb-jar file. You'll likely have to
deploy them as a single unit anyway. You also cannot distribute them across
several servers unless you deploy all on each node. So what's wrong with a single
ejb-jar?
>
>
> Linda (spec lead) gave one (order semantics for strings being different in
> java than in most db systems) but I don't see it as enough to leave it
> completely out of there.
Agreed again. The major database vendors support enough of the unicode ordering
so that the differences are minor. And implementing sorts is well known CS.
>
>
> thanks for your comments.
You're welcome.
>
>
> regards,
>
> robert
>
>
--Victor
===========================================================================
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".
