It's all about encapsulation. Code should be written in one place, and one place only. If you have the same code in two places, something is wrong. CFCs - which are objects in the CFML world - are all about encapsulation. CFCs FTW!
Is that to say that CFMs can't be "encapsulated"? No. With very careful coding and strict architecture in place, CFMs can, in theory, be encapsulated. But they are not, technically speaking, encapsulated, and open up many opportunities for code smell and duplicate code to enter into your application. I personally am not even remotely a fan of stored procedures. You've already enumerated several of the arguments against them. But the bottom line is portability. I am a firm believer in a portable code base, and therefore don't use stored procedures. In the simplest of terms: - controller-level code goes in CFCs (very light/thin, "traffic cop" only) - service/DAO/model-level code goes in CFCs (very robust, intelligent, virtually all logic) - display/view-level code goes in CFMs (very light/thin, displays data and data collection - no business rules/logic) HTH On Tue, Oct 23, 2012 at 8:55 AM, Shannon Rhodes <shan...@rhodesedge.com>wrote: > > I'm drafting our first set of code standards, and I'm running into a > philosophical debate which I'd like to open up to the community. > > Some would say our standard should be to place all queries and as much > execution logic as possible into CFCs. The advantages of this are: most > of your business logic is centralized; if you have to make major changes > (like the time we had to copy most of an app's functionality over but > change a large percentage of the schema references) it's easy to find most > of the relevant code; and, you can often make major changes to an > application without pushing more than one or two files to production. > > Others argue that code only belongs in a CFC if we can expect that code to > be reused. So, if a piece of functionality is extremely specific, and > therefore not likely to be called elsewhere, then why take the extra step > of abstracting to an object. The pet peeve illustrated here is a submit > handler page that contains nothing but a call to a CFC, which apparently > annoys when business logic is expected on the handler page. > > Still others would have us put most logic in stored procedures (which > produces the sub-debate of whether it's redundant to call a CFC that calls > a stored procedure). First, I have to note that we are on Oracle, and > personally I don't find it nearly as easy to debug stored procedures in > Oracle as it is in SQL Server. Second, I have heard that performance > improvement is minimal, and security differences aren't noteworthy provided > that you're using cfqueryparam. Third, we would lose database portability > (there has been talk of moving to SQL Server, which powers our SharePoint > site; of course, there have also been rumblings of moving us to .Net in > which case there's no particular advantage either way to storing business > logic in the database layer versus the application layer). > > Then there are a couple of folks pushing for frameworks, but I don't think > we're quite ready for that yet. > > So...inline code if reusability is unlikely? Everything in CFCs? Forget > CFCs, go to stored procedures? Some rationale for when to use what? Very > interested in hearing your opinions! Thanks. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352978 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
