| Sam,
3 tiers is just an example... those 3 tiers would be your presentation tier, your business tier, and your data tier. There's more information on the web on this stuff than I could cram into 1000 emails, but roughly speaking, they break down like this:
Presentation Tier: display fragments, event model (modelglue.xml), controllers
Business Tier: controllers, model (beans, value objects, transfer objects), DAO/Gateway pattern objects or ORM libraries
Data Tier: ORM libraries or DAO/Gateway pattern objects, RDBMS, persistent storage ala file systems or LDAP
That's your basic 3-tier layered system. You'll notice that I put controllers in layer 1 and 2, and ORM/DAO/GW in layers 2 and 3... just to help point out that these are the "endpoints" of each layer, or the portal by which interaction between the adjacent layers happens. It makes it obvious that your URL params tell your controllers to talk to the model and persistence to set up the data requirements for the next view. Keeping things tiered like this helps both maintenance and support. It's an old approach, but a good one.
You can get even deeper into tiers, too... hence the term "n-tier" being coined, as *I* recall in the early 90's. All it really means is that you have more than 3 tiers, or a variable number of tiers depending on what's going on. When you incorporate something like Tartan, which is what's called a "service layer framework" you end up with several extra tiers by default, something like this: presentation <--> business <--> service <--> command <--> persistence
When you have various types of presentation layers (think MG for HTML and Flex Enterprise for RIA as two different types of front-ends), it can be very useful to have a service-driven architecture like this. ColdSpring is another tool that can be used to help maintain a tiered architecture, but I think for purposes of this example it blurs the lines by being useful to ALL the layers of an application save possibly to presentation, where Tartan is specifically focused on middleware and makes a great example of tiered thinking.
Anyway, I hope that helped and didn't confuse things further!
Laterz, J
------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion
"That which does not kill me makes me stranger." - Yonah Schmeidler On Feb 10, 2006, at 11:59 AM, Sam Clement wrote: 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.
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
On 2/3/06, Jared Rypka-Hauer < [EMAIL PROTECTED]> wrote: 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çade 2. Session.Category is an instance of CategoryRecord and is used as a bean within the application 3. /myApp/views/dsp.viewCategories.cfm needs a query full of Child records to draw itself 4. categoryId is the key upon which dsp.viewCategories.cfm is based
Given 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 http://www.web-relevant.com 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
Doug, that is exactly what I needed. Awesome! Thanks for taking the time to respond.
~Dave On 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
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
|
