There are a lot of articles around about coldfusion components; doing a Google search for the term "coldfusion components" brought back just over 160,000 results, that's an awful lot of information to
digest. I also found Rob Brooks write up on O'Reilly called "Top Ten Tips for Developing Coldfusion Components" written back in 2003 and found it covered a lot of good stuff thats still valid today.
I would, however, like to add a few of my own tips as well as some don't's. It's highly likely that with all those results from Google I'm writing nothing new but I think an occasional review is always good.
No Place for SessionsColdfusion components are no place for session scoped variables. I see it time and time again and in my opinion it's pure laziness! By putting session scoped variables inside of your component you are coupling your component to the existence of that variable in the session scope. The argument I often hear is "the session will always exist before the method is called". Sure the session will always exist, but will the variable inside the session exist? If you need a variable stored in the session then pass the argument as a variable, which brings me to my next point.
I understand that typing all those cfarguments can be a bit time consuming and tedious, and I often see components written without any arguments specified at all, or with the entire Form scope passed as the single argument. I'm not a big fan of this and tend to discourage it's practice. The eclipse RDS CRUD wizard can cut a lot of this time consuming and tedious work out for you and I often start with the auto-generated components and flesh them out from there.
The CFProperty Tag
So what is cfproperty tag and whats it used for anyway? The cfproperty tag defines the properties of a component, for example person.cfc will probably have FirstName, LastName, as two of its properties. But if your component is not going to be exposed as a web-service you really don't need to define properties using the cfproperty tag. The good thing is, however, that if you use the eclipse RDS CRUD wizards to build your components from the database it adds the properties in for you automatically, and you gain some meta data for component introspection with the getMetaData() method.
Using the cfproperty tag doesn't define or initialize variables for you, you still need to to that yourself. I typically do that in a cfscript block at the top of the component, this ensures that the component variables are set to their default values each time the component is invoked. Other people place the initialization code inside the init() function, still others call the init() function just after the cfscript block providing an "implicit" initialization.
<cfcomponent output=false displayname="person">
variables.id = 0;
variables.firstName = "";
<cffunction name="init" output="false" returntype="person">
Reuse your CFC'sComponents were introduced into CFML for a reason and that was/is to provide developers with the ability to structure and reuse code effectively.
If you are going to build something build it in a way that promotes reuse that way you don't have to build it over and over. The extends attribute is a perfect example of providing a mechanism for code reuse if you previously built a user.cfc but you need a few more properties you can extend the existing one to include the properties instead of creating yet another user component.
But it is something that requires a bit of planning.
To DAO or not to DAO
This question requires a bit of "big" thinking. If you are a SQL Server shop and your application will never run on anything but SQL server then do you really need to create all those DAO's for each of your components? I myself am of two minds on this topic. On one hand it does create a bit more overhead but on the other hand all your database access is neatly separated from your business logic. I also find that the larger the project the more sense it makes to separate the data access. If your project has even a slight chance of being rolled out onto other databases then it is, in my opinion, a no-brainer, go with DAO's!
Organize Organize Organize
I can't stress organizing your components enough. If you have a component centric application it's doing you no good to have hundreds of components all in one directory! I generally package my components starting with the com directory, then (perhaps out of vanity) my next folder is gg that basically defines my namespace where components that I write are stored, but it can easily be a short name for the application. I then further sub-divide my components into logical folders that signify their use com.gg.user etc. It makes it a heck of a lot easier to find the component you are looking for if they are not all lumped together.
No recent entries.