Best practice MVC for forms to cfc

Question

Conceptually I would like to keep my logic for a very big
site as MVC as possible. As a cf newbie though I am not sure
whether the strategy suggested by most of the blog/tutorials of
sending (say)
index.cfm's Form.UserName to UsernameCheck.cfm which then
<cfinvoke> Username.cfc
or if I can/should send Form.UserName directly to
Username.cfc
Going direct is more straightforward obviously but then is
the only place to put <cfif> (aka Controller) logic in the
index.cfm page (which defeats my intentions anyway)????
I may be way missing something here, but fwiw I'm getting
kind of spaghetti with multiple <cfelseif> 's for every
index.cfm module so am presently leaning toward redirecting (say)
failed signins to RetrySignIn.cfm rather than back to (essentially)
a <cfelseif> of index.cfm.
Thanks in advance for feedback on your experiences, I realize
this could be done/argued either way but . . .

Answer 1

quote:
Originally posted by:
ProjectedSurplus
by MVC I mean separating code as much as possible into
Model (ie database) -- Controller (Business Logic) --- View
(Presentation Tier)
or very very roughly:
SQL in stored procs -- <cfif> statements in cfc's
(and/or non-display cfm's) --- HTML (using CSS)
In theory thus the code should be more compartmentalized and
hence manageable/reusable.
I guess what I am getting at (as I work through this issue)
is what are your opinions regarding (say)
a single index.cfm page with nested <cfif> clauses
which set out what happens on failed signin attempts but all
redirect back to the index.cfm
vs.
a start index.cfm page which then redirects the user to (say)
a RetrySignIn.cfm page (ie. precluding the need for a <cfif>
check)
My opinion is that simplicity is a very redeeming quality.
With that in mind, I consider putting all business logic into
cfc's for no other reason than to separate logic code from
presentation to be a bad idea because it decreases simplicity and
adds no value.
Putting 100% of your queries into StoredProcedures will
probably increase performance. I don't really know because I've
never really tested it. Also, since I don't use Stored Procedures
for a variety of reasons, I don't know the amount of effort
required to create and maintain them.
This is all subjective. We all have to determine the best way
to handle our own situations.