Cedric Beust 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.
>
> Agreed. Not only is 100 domain objects a common case for any medium-size
> projects (it can be a lot more than that), but we're seeing more and more
> applications that have
>
> - hundreds of EJB's
> - classes with hundreds of methods, each of this method maxed out in size (64k
> in bytecode I think... <sigh>)
>
> Before you dismiss these numbers as either not realistic (what developer would
> come up with something like this?) or "a nightmare to maintain", keep in mind
> that a lot of the code we write by hand today will be generated by tools
> tomorrow.
>
I'm not dismissing the total number of EJB or domain objects. We have hundreds of
both in our applications. I'm simply talking about building applications as multiple
components instead of a single monolithic one. We generate a lot of our code using
case tools. That has little to do with building good components.
--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".
