Heya,
Yeah, I remember just then that the serviceManager is instantiated in the application scope, and upon every call (getServiceManager() it checks to see if it exists If not it creates it and either way returns a ref back.
The problem I'm trying to solve is that when I reference the DataLayerGatewayFactory Object (big word eh) it's only a once of creation vs. many
With Mach-II you have to tread carefully in that you need to keep Listeners application specific, while the rest fairly loose and not as dependent on Mach-II framework for information.
In that the model can be initialize in many ways by Mach-II aware data (i.e. Properties etc) but that's all done via the Listener in question.
The solution Spike and I just nutted out then was to create a config.cfc (forgive me spike if I loose this in translation. I do that at times) that all Listeners know about *(whether they create it every request or simply look in the application scope for its existence but that is logic inside the listener itself.. not a bad thing I guess as typically in most basic mach-ii apps I really only use one listener object).
They then pass in the config.CFC(configBO) into appService.cfc's (blogAppService, newsAppService etc).
Then inside the blogAppService, they would ask the configBO for stuff like
Class blogAppService {
blogAppService(configBO) {
instance.configBO = arguments.configBO;
}
createArticle(articleDTO) {
articleBean = new com.mypath.blogs.articleBean();
articleBean.setTitle(articleDTO.title);
etc..
instance.configBO.getDLGFactory('blog').createDAO('entry').create(articleBean);
instance.configBO.getMessagingService().notifyNewEntrySubscribers(articleBean);
}
}
The catch 22 is that, Listeners & appServices are now application specific in that today I can use them in Mach-II appBlah, tomorrow probably in another etc (appBlahCustom).. but if I go off the reservation (say with farCry) and need to use the "blog logic - ie blog DAO's, DataGateways, Beans etc" they need to have their own appService/Listener fa�ade in front of them, to tell them what to do so partial re-useability is there I guess? Not a bad thing?
Scott.
-----Original Message-----
From: Gary Menzel [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 8 December 2004 11:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [CFCDev] Erm, DataLayer Factory Question.
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]
