CFCs vs. UDFs

Ben Forta recently blogged about a conversation he had with Simon Horwith in London about when to use a CFC versus when to use a custom tag. I completely agree with the conclusion they came to, which was basically that CFCs make sense for logic and data abstraction, and Custom Tags primarily make sense for presentation.

Another interesting question to ask is when should one use CFCs versus UDFs? While I would much rather have this conversation at a Starbucks in London, I guess my weblog will have to suffice.

Since the release of CFMX, I actually find myself writing very few UDFs. I still find them occasionally useful for “one-off” application-specific functionality, but in general, I’m much more inclined to write a component for the following reasons:

  • State: Components can contain state while UDFs cannot. For instance, many native ColdFusion functions require you to pass in the data being operated on in addition to parameters to configure the operation. Having a stateful data structure can promote better encapsulations, make your code cleaner, and in general, be more convenient. Even if your function appears as though it should be static, why not put it in a component and allow yourself some flexibility to expand the functionality in the future?
  • Logical Grouping: I like to be able to put related functions together in a single component rather than just create a bunch of basically unrelated functions. For instance, one could imagine a single date component with 41 different functions as opposed to 41 date-related functions among a total of 235 unrelated functions.
  • Organization: I like having the ability to organize my components into packages. Although you can organize your UDFs into directories, packages provide additional benefits and flexibility.
  • Inheritance: I honestly don’t use a ton of inheritance with ColdFusion components, but I do use it occasionally, and I think my application architecture benefits from it. Although UDFs can certainly invoke each other to achieve the “code reuse” aspect of inheritance, in general, inheritance allows for far more sophisticated modeling.

So how do you decide when to use a component versus a UDF? And who’s up for rewriting all 235 native ColdFusion functions, grouping them into components, and organizing them into packages?

6 Responses to CFCs vs. UDFs

  1. Brian LeRoux says:

    “So how do you decide when to use a component versus a UDF? And who’s up for rewriting all 235 native ColdFusion functions, grouping them into components, and organizing them into packages?”^ lets do this. I’ve blogged that before– ColdFusion needs this badly! Macromedia needs something like gotdotnet.com workspaces to host projects of this kind.

  2. nolan says:

    I work in a shop with 2 big contributing factors to how we write code (much to my disappointment).1. Very few of the programmers here have any sort of OO background at all. anything related to CFCs, classes, etc, scares them greatly. Once in a while I can build a demo and educate my office mates on the benefits of OO, but that is often more work than you’d imagine.2. The amount of legacy (CF 2 and CF 3) code still running on our servers is staggering. The “modularity” of these applications was done with CFincludes in a very “we have to get this running NOW” kind of way.Because of these issues, I’ll often write C-style libraries of UDFs — cfinclude “CustomerUtilities.cfm” and stick any customer related functions into it, replacing the CFincludes and other copy/pasted code in our apps.So I get a little of the functionality from CFCs, without scaring the other programmers. :)If I had my way, I’d rewrite much of it in CFCs and use a more structured framework.Regarding custom tags, if it’s a site-wide quickly reusable function, sometimes I’ll put it in a CustomTag. If it’s used is a more defined area/directory of the site, I prefer UDFs because of their performance, and the C-style syntax I can use in CFscript blocks.2 cents.-nolan

  3. “So how do you decide when to use a component versus a UDF? And who’s up for rewriting all 235 native ColdFusion functions, grouping them into components, and organizing them into packages?”Err, why would you do that? That would be like writing a package for Addition when in CF you can just do x=a+b.

  4. Ray, I was half joking. I’m not sure it would be worth the effort, but it would be nice to have all 235 functions organized in such a way that they are easy to find, and easy to add functionality to. For instance, maybe there’s a String component containing all the string functions. You could then add string functions to the component in a clean way, and have all string-related functionality in one place.Christian

  5. Brian LeRoux says:

    I think it should be done for the next release of CFML. The value of namespaces and organization cannot be understated. Right now ColdFusion is a language leaning towards object orientation– I’m not saying it needs to be enforced but it should would be nice to have at a bare minimum the features actionscript 2 enjoys.

  6. Vui Lo says:

    It’s certainly nice to have packages like cflib in CFC for UDFs grouping. Of course, it might sound repeatitious for CFMX with most of java libraries. However, it’s still benefiacially to developers new to java iff the packages come with good documentation.