Just a correction on how we do it here....
There is ONE instance of a "ServicesManager" class. We dont inherit
from this (as such - well an application space can inherit from other
ServicesManagers - but that's it).
Then there is a "Core" class from which things inherit (they dont have
to - but there is a lot of value in doing so). This base class gets a
reference to an "instance" of the single ServicesManager class
automatically created. Then, classes that inherit from the base core
class can access the ServicesManager through the local instance
reference.
The "ServicesManager" - not the core object - is what manages things
like singletons.
The specific ServicesManager class that is created is determined by a
single entry point that specifies which "application" (not
<cfapplication>) you want the services manager for.
This is all done using package paths to dynamically configure the
application from a single point.
However, I would have thought that MACH-II would already do most of
the things you want.
Gary
On Tue, 7 Dec 2004 18:31:21 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
> The problem I have at present is I'm building an application that makes use
> of two different persist layers. In one install instance it will make use of
> "XML" files, while the other it will use a DB. The two have totally
> different persist logic and so I want to keep the rest of the model uniform,
> while the actual CRUD etc routines specific to the Data Resource type.
>
>
>
> So below is an example of a concept I've been floating around in my head.
> The Manager is kind of a "Service" or even a "FaÃade" I guess, but I settled
> on the concept of it being a manager, in that it will handle all aspects of
> the AppService in question? (think I answered my own question in that bit
> hehe).
>
>
>
> Also keep in mind that I need to make use of a global functions or objects,
> and I'm not sure how to do this via Coldfusion. In other languages I would
> simply "import" the object and use it via its Named path (ie import
> com.mypkg.core.singletonManager and then use
> com.mypkg.core.singletonManager.createSingleton()) so what I've done is
> lifted a concept I saw at my previous work, were we kind of extended all
> objects to a base class of some kind which has these top level routines
> tucked away inside them (whether it be by a dependent object or within the
> extended class itself). Thus you see "createSingleton()" methods.
>
>
>
> I also figure I would use a "DataLayer Gateway Factory" for all my
> DAO/DataGateway object(s) this way I can keep the DAO/DG objects persist
> logic specific but via the typical "abstract factory" pattern, its
> transparent (well should be) to the rest of the model. So at runtime I'd
> pass what type the DLGatewayFactory is (XML or SQL) and it would initialize
> its sub-objects accordingly.
>
>
>
> So here is the concept so far any crit is welcome. I'm using Mach-II as a
> bases for the Framework, thus you will see ApplicationListener, as its
> typically the object that initializes the entire model according to
> configuration settings outlayed.
>
>
>
> Note: its in pseudo code so ignore syntax
>
>
>
> // This is the first object that realistically starts the CFMX application
> (ie Application.cfm equiv)
>
> ApplicationListener extends baseListener; {
>
>
>
> function onAppStart() {
>
>
>
> var DataResourceBean = new com.mypkg.lib.DataResourceBean();
>
>
>
> DataResourceBean.setType('SQL');
>
> DataResourceBean.setDSN('MyDBDSN');
>
> Etc // Note If you set type as "XML" you would go setLocation('pathToXml")
> its versatile enough â that and couldn't settle on a generic verb as I wrote
> this.
>
>
>
> // Create a singleton of the Blog DataLayer GatewayFactory (ie
> in application.scope) â I prefer a snapshot of the data here as the bean
> will not be cached.
>
>
> createSingleton('com.mypkg.blog.DLGatewayFactory',DataResourceBean.getMemento());
>
> }
>
>
>
> // Lets pretend I'm in the app now and I want to make some calls to a
> blogManager
>
>
>
> blogManagerClass extends baseClass {
>
>
>
> function getBlogEntriesByDate(dtArg) {
>
>
>
> return qryEntries =
> getSingleton('com.mypkg.blog.DLGatewayFactory').createDG('Entries').findEntriesByDate(dtArg);
>
>
>
> }
>
>
>
> function saveBlogEntry(args..) {
>
>
>
> var EntryDAO =
> getSingleton('com.mypkg.blog.DLGatewayFactory').createDAO('Entry');
>
> var EntryBean = new EntryBean();
>
> EntryBean.setTitle(arg1);
>
> EntryBean.setBody(arg2);
>
> etc..
>
>
>
> EntryDAO.create(EntryBean);
>
> }
>
> }
>
>
>
>
>
> DLGatewayFactory {
>
>
>
> function init(DRB) {
>
> instance.type = DRB.type;
>
> instance.dsn = DRB.dsn;
>
>
>
> // Even if the type is DB the location key still
> exists.
>
> instance.location = DRB.location;
>
> }
>
>
>
> function createDAO(sDAOType) {
>
> switch(sDAOType) {
>
> case "Entry":
>
> // Now here I could do switch statement
> based on DataResource Type, then do condition logic etc..
>
> // But for now I'll just pass the
> instance scope itself and pretend it's a basic DTO.
>
> return
> createObject('component','com.mypkg.blog[instance.type].EntryDAO').init(instance);
>
>
>
> break;
>
> }
>
>
>
> }
>
>
>
> }
>
>
>
> So Yeah, hopefully the code makes sense but the purpose is that the
> DLGatewayFactory has a certain level of abstraction based on its type which
> grabs the appropriate DAO / DataGateway that's relevant to your persist
> layer type.
>
>
>
>
>
> NOWâ
>
>
> DOES THAT HOLD WATER ehehe.. i.e. commence poking holes in my evil plan.
>
>
>
>
>
>
>
>
> --------------------------------------------------
>
> Regards,
>
>
> Scott Barnes
>
> Senior Network Engineer
>
> Goro Nickel Project
>
>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at
[EMAIL PROTECTED]
