On Thu, Jun 18, 2009 at 3:48 PM, Teaman <[email protected]> wrote:
>
> Adam
> This is very helpful explanation. This is the type of "rules of
> thumb" I'd like to hear from those of you experienced. It may differ
> from person to person but if others post their "guidelines or rules" a
> commonality should emerge with some variations. It's a high-level
> approach to the design. I get most of what you describe below with an
> exception or two so I'll comment below.
>
> On Jun 18, 1:35 pm, Adam Ness <[email protected]> wrote:
> > As to where to put things, Generally I tend to think if it thus:
> >
> > If it applies to only one "page" in traditional coding, put it into the
> > listener for that event.
> > If you can generalize something that happens on 3 or more pages into
> > something that could be used across the system, putting it into a filter
> > might be a good way of handling things.
>
> Not sure this helps on the use of filters. So in my example of the
> common list of records, click to edit one, make changes, submit the
> form, validate, if ok then update the database... it sounds like you
> wouldn't use a filter since it's not something that is used across the
> system. Or is it?
Well, what you're describing here are several events:
1) get a list of records
2) edit a record
3) submit edits
4) commit changes to a record
Given this workflow, since validation only applies to one event (submit
edits) then it's probably not worth putting in to a filter. If on the other
hand, you've got 5 or 6 of these edit forms, and they all do validation, and
you can come up with a good way to validate in a general way, then a filter
might be appropriate, because it'll apply to several events (submit edits to
a customer, submit edits to a shipping address, submit edits to a supplier,
submit edits to a purchase order, etc...)
Basically, filters and plugins are a very simple form of aspect oriented
programming (AOP), which recognize that there are several operations which
are similar, and must do some of the same operations, but on different sorts
of data. Filters apply those common operations only to the events you
specify, and plugins apply those operations to all events.
> The Services should handle interaction with multiple DAOs to define
> relationships for "Higher Level" objects (i.e. when I have a shopping
cart,
> and add an item to it, the service should just recieve an object ("bean")
> with the shopping cart and an collection of items, and should be able to
> tell the CartDAO and the ItemDAO and the CartItemAffiliationDAOs all what
> they need to do to make the database reflect the changes to the Cart.
So a services component goes in the /model and is a higher level set
> of methods that handles calls to methods withing multiple DAOs?
>
That's generally where I put my services, though sometimes I create a
"Controller" directory and put my services in there, and it's generally what
I use my services for. They're also frequently used for non-database
operations (like sending mail, reading and writing XML files, talking to web
services, etc...)
>
> > The DAOs and gateways should be simple passthroughs to Stored Procs, or
> > Dynamic SQL if you're not using Stored Procs.
>
> So where do unique queries go or any query that isn't dynamic?
> I'm not even sure if I understand what is meant by "Services" and
> "Gateways" components. Both go in the /model right? I have been
> putting various methods of specific purpose in what I call a Gateway
> component that isn't a DAO methods. So let's say I have a select query
> that has a join to one or more tables. It's unique. It does not
> necessarily have any dynamic clauses in it. Does that go into a
> Gateway or a Services or ?
>
When I said "Dynamic SQL" I basically meant anything that's in a <cfquery>
and not a <cfstoredproc>. I typically roll my Gateways and DAOs together,
since I don't see a solid reason why to keep them separate, but regardless
of how you choose to do it, they either belong in the "/model" directory, or
occasionally I'll put them in a separate "/db" directory. I especially
choose the second when I've got a whole lot of them. Since there's at least
one DAO per table in my database, I frequently end up with 20-50 DAOs, which
with my "beans" and "services" makes my /model directory unmanageable.
That's when I split off to a separate "/db" directory.
> The View should only contain <cfoutput>, <cfloop> and very sparing <cfset>
> > for turning things in the event scope into local variables.
>
> I agree with this but would add branching tags such as <cfif> and
> <switch>. There are conditional aspects to the view for hiding or
> revealing content. Was this an intentional omission or an oversight?
>
You're right, it was an oversight :) Though be careful with CFSwitch. If
you're switching out more than a few lines of HTML, you should probably just
be splitting it up into multiple views and dynamically announcing a
different event based on which view you want.
> > The Model is where you should define relationships. For example, your
> > "Cart" object should have an "AddItem" method, that shows that there's a
> > relationship between a cart and an item, and a "setCustomer" method, to
> show
> > that there's a relationship between your customers and your carts.
>
> This suggests that the Services and Gateways you spoke of earlier are
> NOT in the Model?
>
It's a blurry line. There's more to an MVC architecture than just Model,
View and Controller... Services and Gateways/DAOs are more "Model" than any
of the other categories, but aren't "Model" in a traditional MVC
architecture. They're something else. I'd call them Object/Relational
Mapping objects, hence why I put them in a "/db" directory.
In terms of conversation, I tend to use the word "Model" like other people
use "Bean". Model is the actual data model, as reflected in memory in the
ColdFusion server. I don't tend to use the "Bean" pattern, (I prefer the
"VO" pattern that Cairngorm uses), so I feel weird referring to my data
objects as "Beans"
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to Mach-II for CFML list.
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/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
-~----------~----~----~----~------~----~------~--~---
