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 -~----------~----~----~----~------~----~------~--~---
