Victor,
thanks for the response. Comments see below.
> 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.
> have developed reference versions of a several so that object A in one
> subset of the model can reference object B in another subset without also
> including all of object B's referenced objects. The reference versions
> usually only contain the most important attributes of the domain objects
> they represent. The small overhead in keeping them updated is easily offset
> by the freedom to develop various parts of the application independently.
A valid approach.
>
> 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)?
>
> > - EJB QL will not be a step ahead as far as portability is concerned
> > because of a missing order by clause. server vendors will most likely
> > provide proprietary ways to define the finder queries in SQL, so much for
> > portability.
>
> I agree here. Order by is simple for the contain vendor to implement even
> if all data sources don't support it. I cannot think of a good reason to
> leave it out of the spec.
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.
thanks for your comments.
regards,
robert
>
> --Victor
>
> -------------------------------------------------
> "I've figured out the difference between scientific
> knowledge and business knowledge. Scientific knowledge
> depends on facts, logic, and the rigorous testing of ideas
> in the laboratory and the field. Business knowledge
> depends on the assertion of pet biases with great
> confidence and exorbitant billing rates." --Bob Lewis
>
> ===========================================================================
> 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".
