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:
(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:
(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.
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>
<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>
<!--- 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.
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