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.
-David
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 <[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
