While I do like the idea of splitting up any monolithic code in the
DefaultContinuum class, I don't support splitting data-access code from
itself.
IMO, breaking data-access stuff by model-class is asking for trouble,
since it doesn't allow a good mapping of data-access functions for
managing relationships between multiple model classes. It think we can
still gain a lot by separating the DAO stuff into a small number of DAO
classes (maybe only one? definitely not one-per-model-class), and
separating other bits of logic into coherent classes that are controlled
by the DefaultContinuum class. For DAOs we need to avoid both the case
where all DAO functions are stuffed in a single class Just Because -
making it hard to maintain by sheer size - and the case where DAO
functions dealing with object-object relations is shoved into a class
where it doesn't make sense (i.e. on one of the classes' DAOs and not
the other).
-j
Trygve Laugstøl wrote:
On Wed, 2005-12-14 at 14:58 -0800, Carlos Sanchez wrote:
On 12/14/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
I still disagree with splitting up the ContinuumStore into a set of
DAOs. I've never seen the advantage of having a single DAO for each
domain object.
They will be reusable in other applicaitons. If we're thinking about
creting other applications, like repository manager, we'll share a lot
of common objects between them.
I have yet to see an example of this idea working in real life. I
understand that you'd want to manage different sets of objects, but like
in Continuum the Project and Build objects are to tightly coupled that
you can't possibly store Project objects in one database and the Build
objects in another.
--
Trygve
