Good deal. I'll go through it and tweak the next time I hit the code to fit my needs. I'm not sure which way to tweak just yet but glad to hear I'm not alone.
Thanks! (great list btw; most helpful I've been on except the AZ Flash UG list) --- John C. Bland II http://www.johncblandii.com http://www.johnandseason.com http://www.twitter.com/johncblandii --- Suggested sites: http://www.lifthimhigh.com - "Christian Products for Those Bold Enough to Wear Them" http://www.sportsmatchmaker.com - "What are you doing today?" On Fri, Oct 9, 2009 at 3:35 PM, Sean Corfield <[email protected]>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
