Hello, I try to remain organized when creating CFCs and writing methods to them. I would like to develop a methodology or best practice to create an easy to remember and logical structure of them. I mean I found that there are four main categories of my methods: 1. The basic database interaction related CRUD methods for creating, deleting, updating and reading functionality. 2. Other database related methods eg. for getting smaller pieces of information (maybe a list of product IDs) from the database. In this case I usually I don't use the list method from the CRUD because that would return a lot of excess data aswell. 3. Methods that solve not db related small tasks eg. calculations. 4. Methods that invokes other methods and link them into a workflow in order to run a more complex process. I was thinking about whether It would be beneficial to create this four type of CFCs and sorting out my methods to them instead putting all of them into one. I mean I would create an orderCrud, orderOtherDb, orderTasks, orderProcess for the order related methods and would sort them according. The names I used here are not too good they are just for the sake of explanation. I try to develop some method for the long term and would qurious about how others dealing with this situation. Are there any generally used best practice or are there any good article about this subject on the web? Thanks, Prisec
Well, the important thing to remember is that it doesn't matter whether you have one CFC with 5000 methods, or 5000 CFC with one method each. (Of course that would slow you down tremendously). I have written methods before that contained both SQL statements, logical equations, and validation methods, Then again, I have also written methods that separate those individual levels of logic. There is no right or wrong way, it just depends on if you plan on keeping those methods intact for a period of time. If you are constantly adding new content to the CFC then maybe a standard for how you develop should be invented. It also depends on how many people see the code. If you are the only one who sees the code, make sure you at least document how you decide to do it, otherwise when you comeback to the code after a long period of working with something else, you won't have a headache trying to remember why you did things the way you did.
It's been awhile, but I've written some pretty heavy duty CFCs. What I found worked best for me was keeping things as object oriented as possible (but I've been a C++ for a looong time). So for example...maybe keep database stuff in a database CFC, display stuff in a display CFC, etc. One thing I particuliarly like to do is write a function that wraps the silly <cfquery>. So you can call something like <cfset MyQuery = DBCFC.Query("select * FROM Table;")>
Well technically, thats not OOP if you are using a CFC for display purposes. The object that a CFC represents should not know anything about the application, except what you pass into it. If the CFC becomes dependent on one project, and can't be used by more than one project than it defeats the purpose of using a CFC. CFC(s) should be written so that they can be used again. That way you don't have to write the same functions again if you build a similar application.