I think that one of the best uses of CFC's (and UDFs and custom tags) is to
abstract or "hide" a lot of code behind simple function calls or custom
tags so you can make changes in one place and have of in effect globally. Or
if you abstract part of your code, like the database layer, you can make
(some times drastic) changes and have the rest of the app go uneffected by
the change.
Take a database abstraction layer (like Steve Bryant's DataMgr) as an
example. In your standard CWACK CFM page/Action page paradigm let's say that
your "action pages" have INSERT, UPDATE and DELETE queries coded on a CFM
page (or several pages) and you make CRUD calls to the database in four or
five places in your app; You have the option (for the purpose of example and
not best practices) of pointing your form or list pages at the page(s) that
contain the queries, or including the page(s), or copy and pasting the
queries to several pages in your site. Now if you make changes to your
database (and you will more often than not) you have to make changes to all
of those queries and/or pages.
Now if you abstracted your database layer using CFC's you only need to make
changes in one place (I guess that is code reuse).
So with DataMgr (or any other Database abstraction layer) you are just
making function calls to a CFC's like so:
<cfset employee_id = Application.DataMgr.saveRecord("employees",Form)>
Now you can make tons of changes to your database and you don't have to make
changes to any of your (simple) CRUD queries. DataMgr creates the queries on
the fly so that may not be a good example. But even with Transfer all you
need to do is regenerate the code created by Transfer with the new database
structure. Your view pages (read: cfm's) are totally agnostic to, and knows
nothing of, the database. You can swap out database engines or even rewrite
the function calls to use web services to update your data and it will have
little or no effect on your views (in theory that it, it is seldom that
easy).
Or say you find a bug in a function or chunk of code that you have copy and
pasted all over the place, you have to make changes to each one of those
chunks of code.
Here is another example but it takes the form of a custom tag (but the
concept is the same). We used to use Googie spell as the spell checker on
our intranet (this predated my employment btw). There were a couple of
hundred instances of the spell checker strewn about the intranet and all of
them were copy and pasted in there. One day Googie spell stopped working for
some reason (I forget why).
Now we had to update several hundred chunks of code to change. What a
nightmare. When we settled on a new spell checker I wrapped inside a custom
tag. We still had to update a bazillion instances of the old spell checker.
But now we can change the functionality of it or even swap it out for
another spell check engine and all I need to do is change one or two files
and the changes are global.
As Forrest Gump put it "...that's good! One less thing."
G!
On Tue, Sep 8, 2009 at 10:39 AM, Phillip Vector
<[email protected]>wrote:
>
> Besides the code being reusable, is there a specific reason why I
> should use a CFC rather then a CFM file?
>
> I mean, from what I understand about CFC's, they use the same
> processing power as a file cfincluded. Am I incorrect in this? Is
> there a compelling reason to use CFCs instead of "normal code"?
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Want to reach the ColdFusion community with something they want? Let them know
on the House of Fusion mailing lists
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:326122
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
