continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: [Proposal] Continuum refactoring
Date Fri, 16 Dec 2005 22:30:33 GMT
Just to jump in.  I don't really see the limitation with the current  
ContinuumStore object.  In fact, I would say the only real issue I  
see around it is that too many components are dependent upon it which  
makes Continuum somewhat database-centric.  In most cases these  
components are just using it to pass parameters to each other in an  
indirect way and don't actually need to be updating or hitting the  
database over and over again.

To my eyes, it seems that everything from the BuildController down  
doesn't actually need a store of any kind.  So far it seems  
everything under that Component just needs the exact same instance of  
Project, BuidDefinition and BuildResult.  All those objects could be  
wrapped into a new object BuildTask (or something similar) which  
could be a standard part of the context map sent into any build- 
related actions.  Then several references to the ContinuumStore could  
be removed.

There are some components below the BuildController that rely upon  
the ConfigurationService which needs the ContinuumStore to grab the  
SystemConfiguration object, but I would say maybe its a bit of a  
false assumption that the SystemConfiguration is stored in the same  
place where the Project and BuildDefinition information is stored.   
That is to say, if there is more than one system building the same  
set of projects (as in a distributed build system) the  
SystemConfiguration for each build agent will likely not be stored on  
the master build system serving as the definitive source of Project  
and BuildDefinition information.

To summarize my thoughts:

  1. One big ContinuumStore is fine as you are likely to have only  
one database and it makes it really clear what components are  
database-aware.  Continuum doesn't have 50+ tables (data objects) so  
taking the EJB approach and having one DAO (EJBHome) per table is not  
really necessary.  It gives you that nice organized feeling to have  
it broken up into small tiny pieces, but it doesn't help with  
maintenance as a change to the database is universal and affects  
everything.  It also would make implementing a new store an arduous  
task.  This part is purely anecdotal, so take it with a grain of  
salt, but those small DAO classes tend to fill up with application  
logic over time and eventually become irreplaceable.

  2. Using the store to pass parameters is a no-no and needless  
dependence on the store is bad for components you may wish to reuse  
in a distributed system.


On Dec 15, 2005, at 2:43 PM, John Casey wrote:

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