Doug's Resume
OO Lexicon
Chat with Doug!
Recent Entries
You may also be interested in...

heaters
hotels boeken in 7 sec
Engagement Rings
Online Dating Australia




SURF'S UP!
You:
Your Web Site:
<< July, 2008 >>
SMTWTFS
12345
6789101112
13141516171819
20212223242526
2728293031
Search Blog

ColdFusion Jobs
Recent Comments
Categories
Archives
Photo Albums
Funnies (5)
Family (3)
RSS
Reciprocal Links

Powered by
BlogCFM v1.11

02 March 2007
Dynamic Data Stores: A Model-Glue/OO Case Study
The scenario is that my team and I are building an app that must be able to seamlessly communicate between multiple datastores; one local, and the remainder remote and accessible via web service calls. In order to accommodate this, I've created a DataStoreAdapter component that has an instance of each of the specific data store interface components injected into it by Coldspring.

The challenge here was to find a way to dynamically call the appropriate methods on the appropriate data store object. After several different attempts, following is what I came up with that works (you may want to first sneak a peek at the visual I added to this post):


1. My user object (nestled within my user service layer) calls a generic method (named appropriately "callMethod") on the DataStore Adapter:

<cfset stResults = getUserDataStoreAdapter().callMethod(argumentCollection=arguments) />

(note: one of the arguments being passed in within the argumentcollection is 'methodname' with a value of 'getUserData')

2. The 'callMethod' method in the datastore adapter dynamically invokes the appropriate generic method:
    <cffunction ACCESS="public" name="callMethod" OUTPUT="false" RETURNTYPE="any" DESCRIPTION="I am the generic method that calls the appropriate backend system.">
        <cfargument name="backendSystem" TYPE="string" REQUIRED="yes" HINT="I am the name of the targeted backend system" />
        <cfargument name="methodName" TYPE="string" REQUIRED="yes" HINT="I am the name of the method to call within the targeted backend system" />
        <cfset var local = structnew() />
       
        <cfinvoke argumentcollection = "#arguments#" method = "#arguments.methodName#" returnvariable = "local.myResults" />
       
        <cfreturn local.myResults />
    </cffunction>

(arguments.method name in this case = "getUserData")

3. The generic method that was called invokes the appropriate specific method to return the autowired object needed, then the appropriate method is called from the specific backend object returned by the invoke:
    <cffunction access="private" name="getUserData" OUTPUT="false" returntype="any" DESCRIPTION="I am the generic getUserData function" >
        <!--- incoming argument collection is implied, no need to specify individual arguments. --->
        <cfset var local = structnew() />
       
        <!--- step 1: Make the call to the appropriate backend system... --->
        <cfinvoke  method = "get#arguments.backendSystem#User" returnvariable = "local.myObject" />

        <!--- we're invoking the backend-specific method from the appropriate object in the following line... --->
        <cfreturn local.myObject.getUserData(argumentcollection=arguments) />
    </cffunction>

(notice this specific method is private...can only be invoked by the "callMethod" method...)

4. The returned data is passed back up the calling chain to the original calling component.

Here's a diagram that might help to visualize it better.

Back to Top
All data massaging is encapsulated in the lowest level backend system components, so that each of them will return a consistent data set regardless of what they themselves are receiving from the backend system. And, as our upper management dictates that we interface with yet ANOTHER wack backend system, all we'll need to do is create the low level component and wire it in to our datastore adapter service!

Anyway, I was pretty pleased with how we addressed this situation so thought I'd share it.

Doug out.



Posted by dougboude at 4:35 PM | PRINT THIS POST! |Link | 1 comment
Subscription Options

You are not logged in, so your subscription status for this entry is unknown. You can login or register here.

Re: Dynamic Data Stores: A Model-Glue/OO Case Study
This is AWESOME!! Thanks for sharing it with the community, Doug.
Posted by Jay Greer on March 2, 2007 at 10:34 PM

Name:   Required
Email:   Required your email address will not be publicly displayed.

Want to receive notifications when new comments are added? Login/Register for an account.

Time to take the Turing Test!!!

What letter comes four place(s) after the letter T?
Type your answer exactly two time(s) in the designated box.

Type in the answer to the question you see above:

Your comment:

Sorry, no HTML allowed!