Excellent. I much prefer that. Thanks,
--- 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 2:51 PM, Dan Wilson <[email protected]> wrote: > This is what EntryStats does: > http://modelglue.pastebin.com/m445ad97 > > It is the authoritative object for dealing with EntryStats. See how I > grouped behaviour together? This means I can always deal with the EntryStats > object when I need to get stats, get a query of stats, set up a chart data > structure of stats... > > There is no need to have an EntryStatsDAOGatewayWhatever, because it adds > no value. > > > > > DW > > On Fri, Oct 9, 2009 at 3:44 PM, John C. Bland II > <[email protected]>wrote: > >> You touch on exactly how I feel about it. >> >> So question, in your EntryStats does it deal with all things entry stats >> or do you have a separate cfc for the different actions? It seems you setup >> more of a commands architecture where this cfc does that and that only. >> Reminds me of a lot of the AS3 work I do. >> >> --- >> 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 1:59 PM, Dan Wilson <[email protected]> wrote: >> >>> 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 >>> >>> >>> >> >> >> > > > -- > “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 -~----------~----~----~----~------~----~------~--~---
