Hi Jared,
I know this thread is a bit old but I been meaning to ask you about this since I'm still learning about OO architectures.
1) What 3-tiers are you referring to here?
2) When you implement a service layer in MG, where do you typically instantiate and configure your Gateway, DAO, etc. objects (or reactor/ARF record objects) - in the service or in the controller?
Cheers,
Sam
OK, here's one for ya, smarty-pants. :)In a 3-tier MVC application where you have controllers, a service layer, and a persistence layer, how do you structure the model to call CategoryRecord.getChildQuery()? Let me give you as simple an example as I can come up with. Warning: I'm not terribly good at "simple" sometimes. ;)Assuming the following:1. ControllerX has access to the sessions via SessionFaçade2. Session.Category is an instance of CategoryRecord and is used as a bean within the application3. /myApp/views/dsp.viewCategories.cfm needs a query full of Child records to draw itself4. categoryId is the key upon which dsp.viewCategories.cfm is basedGiven these things, the query is (should be, is best, or orghta been) obtained for the view via which of the following?1. Controller X gets an instance of CategoryService and calls CategoryService.getCategoryChildren(SessionFacade.get("Category"),"array")CategoryService. getCategoryChildren() takes a CategoryRecord as an argument and simply cfreturns arguments.Category.getChildQuery()Controller X sets the result into an even object key:<cfset arguments.event.setValue("childrenQuery",CategoryService.getCategoryChildren(SessionFacade.get("Category"),"array"))>2. ControllerX uses the following statement:<cfset arguments.event.setValue("childrenQuery",SessionFacade.get("Category").getChildQuery())>3. ControllerX includes the following statement:<cfset arguments.event.setValue("Category",SessionFacade.get("Category"))>dsp.viewCategories.cfm contains the following statement:<cfset childrenQuery = ViewState.getValue("Category").getChildQuery()>
I'll grant you that the application itself and its overall architecture will define some of this because it's going to be based on consistency with any work that's already been done, what other team members want to do and how you can sway them, and whether or not dsp.viewCategories.cfm needs other attributes from Categories beyond just the query... maybe. I still don't see a problem with having the Service make the call to get the query that the controller sets into the event AND setting the Category instance into the event as well.
Personally, in a 3-tier architecture, what would be the point of #2 or #3? It sort of defeats the purpose of having a third tier. You might as well have a 2-tier application at that point and just have methods in your controller like getRecord("RecordName") and not bother with the service layer. As we're all so fond of saying... it's all about tradeoffs, but in this case I think that the extra abstraction given by a very simple function in CategoryService (4 lines of code including open/close cffunction tags, a cfargument tag and a cfreturn) maintains the sort of consistency that a 3-teir application is intended to give and keeps the correct operations happening under the direction of a consistent set of objects.
On the other hand, it may just not be worth the trouble.
I think, however you do it, that consistency is king here... so if you set Category to the view and then call getChildQuery() in the view as well, doing it that way consistently will at least keep the application maintainable.
Any thoughts?
Laterz,
J
------------------------------------------------
Jared C. Rypka-Hauer
Continuum Media Group LLC
Member, Team Macromedia - ColdFusion
"That which does not kill me makes me stranger." - Yonah Schmeidler
On Feb 3, 2006, at 7:22 PM, Doug Hughes wrote:My pleasure. I always answer the easy ones ;)
Doug
From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] On Behalf Of Dave Shuck
Sent: Friday, February 03, 2006 5:21 PM
To: [email protected]
Subject: Re: Reactor For CF hasMany of the same object... is that doable?
Doug, that is exactly what I needed. Awesome! Thanks for taking the time to respond.
~DaveOn 2/3/06, Doug Hughes < [EMAIL PROTECTED]> wrote:
Dave,
Why not have a table like this:
Category:
categoryId
parentId fk to category.categoryId
Then have an xml config like this:
<object name="Category">
<hasOne name="Category" alias="Parent">
<relate from="parentId" to="categoryId" />
</hasOne>
<hasMany name="Category" alias="Child">
<relate from="categoryId" to="parentId" />
</hasMany>
</object>
That'd give you method like this:
CategoryRecord.getParentRecord()
And
CategoryRecord.getChildQuery() / getChildArray()
Doug
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dave Shuck
Sent: Friday, February 03, 2006 5:00 PM
To: [email protected]
Subject: Reactor For CF hasMany of the same object... is that doable?
I am working with a shopping cart application in which I want to allow a Category to have infinite levels of sub-Categories. My thought was to have a relational table with a ParentId/ChildId scenario where both Ids were actually CategoryIds. If I understand the <link name="foo" /> in the config XML file, "foo" would be a table that held column names identical to the primary keys of the two related items. If that assumption is correct, I can't do a hasMany of objects of the same type using native Reactor stuff can I? Does anyone have a thought on the best way to approach that?
Thanks.
--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com
--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com
