I don't really use gateways myself. Regardless of whether I'm managing data with an ORM or with straight up SQL, I usually have an object that gets requests for certain types of data. I often don't name them with xxxService, xxxManager, or any such thing, preferring more descriptive names... like EntryStats.cfc or currentUserLoader.cfc
If managing that data gets really complicated, I might break out into child objects or something, but usually I find that to be an unnecessary layer of abstraction. It really depends. If you ask yourself, "Does the introduction of this layer simplify something?" and if the answer is yes, then add the layer. If it is simply a layer that you "might need later" then I'd consider leaving it out. As long as consumers of the data always talk to the front-line object (EntryStats.cfc or CurrentUserLoader.cfc) then you can refactor downwards without screwing up a lot of code. Always go for "Just Enough Architecture", versus, "Everything I Might Need" DW On Fri, Oct 9, 2009 at 2:44 PM, John C. Bland II <[email protected]>wrote: > I saw Sean's post about it a while back and have never been a gateway'er > but I'm finally seeing the use. > > So the question is what is the best approach here? Here is what I have: > > <controller id="PlayerController" > type="cfcs.controller.PlayerController" beans="playerService"> > <message-listener message="GetPlayers" function="load"/> > </controller> > > ...[controller method] > <cffunction name="load" access="public" output="false" > returntype="Any"> > <cfargument name="event" required="true" /> > <cfset event.setValue("players", > beans.playerService.getActivePlayers()) /> > </cffunction> > > ...[service method] > <cffunction name="getActivePlayers" access="public" returntype="Any"> > <cfreturn > variables.dao.getByAttributes(argumentCollection={StatusID=2}) /> > </cffunction> > <!--- dao is injected via coldspring ---> > > ---[the beans] > > <bean id="playerService" class="cfcs.services.PlayerService"> > <constructor-arg name="dao"> > <ref bean="playerDao" /> > </constructor-arg> > </bean> > > <bean id="playerDao" class="cfcs.dao.PlayerDAO"> > <constructor-arg name="transfer"> > <ref bean="transferFactory" /> > </constructor-arg> > </bean> > > 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? > > Also, TransferAdapter isn't a 1:1 with Transfer.cfc. Am I missing something > there? > > To resolve it I switched to transferFactory which is basically a bean > factory...well...you guys know this stuff already. lol. > > <bean id="transferFactory" factory-bean="ormAdapter" > factory-method="getTransfer" /> > > 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? On the > flip, is that the reason for the Gateway? If so, wouldn't it be the same as > having to change the service? > > Anyways...I was supposed to only fool with this for a few hours but I'm > getting a bit addicted to MG. I'm def' sniffing the Glue, Dan. > > --- > 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?" > > > > -- “Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.” Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
