On Jun 18, 4:14 pm, Adam Ness <[email protected]> wrote:
> 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...)
I oversimplied my example. Actually it's the typical Add/Edit/Delete
scenario. List records and provide a way to edit each, delete each or
add a new record.
So the details form for editing the record is usually used for adding
a new record and reviewing for deletion too. SO that's 3 actions based
on one form. There's also the... what to do when an error in the
submit data if encountered... display the error and the form data in
the form again.
The primer on this wiki suggests using a filter I guess (doesn't say
why) because of the branching on the submit button value. It displays
Add for a new record, Update for edits, and Delete if an existing
record. The filter detects which button was pressed and responds with
the appropriate event to use. But I"m stuck on where the validation
logic goes. In the filter? In a gateway or other component such as a
validation component (that's where I'm leaning towards at this point
based on your suggestions.) Matt says use a listener but not sure how
the validation results branching should be handled. I guess I can use
the event-handler event-mapping to handle that? But then why does the
primer suggest the filter. I think the filter should detect the button
pressed on the form and could call methods in a validation component
to check each field value. Then a return value of false would trigger
an annouceEvent() based on that value.
> 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...)
Some of my form action code also responds (after validation) by
sending email. You are suggesting that code goes in a "services"
component?
Also often do logging somewhere of what happened. Where does that
code go? In this same "service" component or do I rely on some
Framework magic for handling that? I am aware M-ii has logging
features but have no idea at this point how that all works. More
reading some day.
> > > 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.
This is very helpful.
In my thinking I use a gateway for special case queries but the DAO
for the typical table CRUD (add/read/update/delete) operations on the
table.
> > 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"
What is VO? If you don't use bean pattern then do you not have getter/
setter methods for each column in the table?
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
