On Fri, Oct 9, 2009 at 11:44 AM, John C. Bland II
<[email protected]> wrote:
> Now, I'm curious if the gateway (or DAO in my above naming) is even needed.
> It feels like an extra abstraction layer that probably isn't very necessary.
> Granted in this case the code does handle a bunch of extra junk but it seems
> the Service should talk with Transfer and pull the data itself. Thoughts?
Well, it depends :)
You're right about the "duplication" when your service methods act as
simple delegates to your persistence layer and in a lot of apps the
separation of data gateways from services doesn't buy you much (except
a lot of "redundant" delegation methods in your service). As your
application gets larger and more complex, separating all the raw data
access out of the business logic of the service can be beneficial
tho'...
Here's how I tend to approach it:
Initially, I write my data access methods directly in my service CFC.
Yes, I really do! If the service gets "large" (subjective) or I start
to find I need the same data access in other services, I refactor to
push data access methods into a separate gateway CFC (these days I
prefer the term data gateway over data access object).
If I then find myself with more than a few straight delegation methods
(and because my methods start off in the service, they retain their
name when moving to the data gateway), then I add onMissingMethod()
instead:
<cffunction name="onMissingMethod">
<cfargument name="missingMethodName"/>
<cfargument name="missingMethodArguments"/>
<cfset var __result = 0 />
<cfinvoke component="#variables.gateway#"
method="#arguments.missingMethodName#" returnvariable="__result"
argumentCollection="#arguments.missingMethodArguments#" />
<cfif isDefined("__result")>
<cfreturn __result/>
</cfif>
</cffunction>
Now my controller - or any other service - can call methods on the
service and if they are simple data access methods (i.e., not
implemented in the service), they are automatically delegated to the
service's primary data gateway.
> Also, TransferAdapter isn't a 1:1 with Transfer.cfc. Am I missing something
> there?
Correct. The ReactorAdapter and TransferAdapter exist solely to
provide a common API for Model-Glue's generic data messages and
scaffolding.
> Is it common to pull the direct transfer object (getTransfer()) or should I
> learn to work with the Adapter so my code isn't bound to Transfer?
You can get the TransferFactory directly from here:
<bean id="ormService.Transfer" class="transfer.TransferFactory">
<constructor-arg name="configuration"><ref
bean="transferConfiguration" /></constructor-arg>
</bean>
i.e., ormService.Transfer is what you want, or you can alias it:
<alias alias="transferFactory" name="ormService.Transfer" />
I wouldn't recommend trying to use the adapter directly.
The only benefit I can state with certainty for completely
encapsulating the use of Transfer completely from day one in a bunch
of data gateway CFCs is to prepare for a migration to some other ORM
(e.g., Hibernate) so that you don't have to change your service layer.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
--~--~---------~--~----~------------~-------~--~----~
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
-~----------~----~----~----~------~----~------~--~---
