continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject Re: [Proposal] Continuum refactoring
Date Thu, 15 Dec 2005 22:43:30 GMT
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 

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).


Trygve Laugstøl wrote:
> On Wed, 2005-12-14 at 14:58 -0800, Carlos Sanchez wrote:
>> On 12/14/05, Trygve Laugstøl <> 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

View raw message