ModelFactory interface (was: maven-model-tools to ...)

[Alex Karasulu <ao...@bellsouth.net>]

Hi,

Sorry my shxty mail client and jittery cafinated fingers prematurely
sent my last email incomplete so I'm resending it again.

As I recommended I would use the factory method pattern here where
the creator is the factory.  The ModelFactory interface is the 
interface for all factory implementations.  I would go with something
like so which is based on CRUD:

/**
 * Creates a new Model within a backing store using supplied parameters.
 *
 * @param a_model the Model to create within the backing store
 * @param a_params the parameters needed to access the backing store
 * @throws ModelStoreException if there is a failure accessing the backing
 *     store or the Model already exists within the backing store
 */
void create( Model a_model, Properties a_params ) 
    throws ModelStoreException ;

/**
 * Reads a Model from a backing store using supplied parameters.  Note
 * that the primary key uniquely identifying a Model is a composite key
 * based on the artifactId and the groupId.
 *
 * @param a_artifactId the id of the artifact associated with the model
 *     as a part of the composite primary key
 * @param a_groupId the id of the group associated with the model as a
 *     part of the composite primary key
 * @throws ModelStoreException if there is a failure accessing the backing
 *     store or the Model specified by the artifact and group ids does not
 *     exist within the backing store
 */
Model read( String a_artifactId, String a_groupId, Properties a_params )
    throws ModelStoreException ;

/**
 * Updates a Model within the backing store using supplied parameters.
 *
 * @todo consider the behavoir to default to a create op if the Model 
 *     does not exist within the backing store
 *
 * @param a_model the Model to update within the backing store
 * @param a_params the parameters needed to access the backing store
 * @throws ModelStoreException if there is a failure accessing the backing
 *     store or the Model does not exist within the backing store
 */
void update( Model a_model, Properties a_params ) 
    throws ModelStoreException ;

/**
 * Deletes a Model from the backing store using supplied parameters.
 *
 * @todo consider the behavoir to default to a no op if the Model 
 *     does not exist within the backing store instead of throwing 
 *     an exception
 *
 * @param a_model the Model to delete from the backing store
 * @param a_params the parameters needed to access the backing store
 * @throws ModelStoreException if there is a failure accessing the backing
 *     store or the Model does not exist within the backing store
 */
void delete( String a_artifactId, String a_groupId, Properties a_params )
    throws ModelStoreException ;

Ok so let me make some statements on the bs I just carved out here.
First I just made up an exception type to use here which would wrap
the gambit of exception types that may result from the underlying
factory implementations. Second you never know what parameters are 
going to be needed by an underlying implementation so I use a set of
Properties here like the way JNDI does to accomodate the needs of the
underlying provider.  Now why use Properties instead of Map or a
Hashtable as does JNDI?  #1 there is a set of Properties that are 
already loaded from the project.properties files and #2 if users 
were to add model specific parameters it would be there - there 
would be no project.xml to read after all.

So model factory implementation and it's connection parameters can 
be stored within the project.properties file and accessed by the
factory via the Properties argument.

As I mentioned before the ModelFactory interface is the abstract
creator and the implementations are concrete creators.  The product
is the Model.  Note that it might be best to factor out interfaces
for Model and its subordinate object classes in the containment 
model.  I would use the current implementation classes as DefaultXYZ
classes.  This allows factory implementors to implement their own model
value objects and still be able to extend other superclasses.  Most 
implementations will however most likely use these default model 
value object implementations anyway.

Oh and another thing if you store some type of property for the
fully qualified model factory implementation class name within
the project.properties file the proper factory implementation can
be instantiated that way.  If the property is not specified the
default implementation (XML based factory) can be used instead.

Can't think of another better way right now to manage factory 
creation than the above but I'll reply back to myself if a better 
means comes to mind.

Alex



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: ModelFactory interface (was: maven-model-tools to ...)

[Jason van Zyl <jv...@maven.org>]

On Mon, 2004-01-12 at 01:28, Alex Karasulu wrote:
> Hi,
> 
> Sorry my shxty mail client and jittery cafinated fingers prematurely
> sent my last email incomplete so I'm resending it again.
> 
> As I recommended I would use the factory method pattern here where
> the creator is the factory.  The ModelFactory interface is the 
> interface for all factory implementations.  I would go with something
> like so which is based on CRUD:

I'll take a peek and see what can be gleaned but essentially Plexus is
the factory. Plexus components with the addition of a constructor are,
in fact, Pico compatible so in hardcode deployments the user will choose
the component directly. Currently the one implementation out of many is
chosen by configuration. The avalon personality in Plexus still has the
selector, which I've never liked but there will be something similiar in
Plexus, a CompositionCriterion, which will help in that regard. I plan
to leverage Plexus for everything in the assembly arena.

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org