I think you are going to get varied responses here. I have always been a fan of encapsulation even before CFC's and MVC, I would put all DB queries into separate files and code into a separate file and these would either be cfincluded or CF_tags. Sure it does seem pointless sometimes to do this for a couple of lines of code that wont be used elsewhere, but in the event someone does need to change it one day, it is easier if it is easy to find for maintainability, but then on the other hand if all files are named sensibly then everything should be easy to find anyway regardless. But if you are going to have standards and protocols, you should really stick to them all the time and not just randomly break them.
StoredProcs should certainly be used if they provide a worthwhile performance boost, only testing will tell you this. If there is no real benefit then I would not use them just for the sake of it as it adds unnecessary complexity to the maintainability especially where the developer does not have access to the db server to edit the storedPROC. It rather depends on your team, if you have a dedicated DBA who is a guru at stored procs and performance tuning queries, then best to good use of him. If it is the cfdevs writing the stored procs and they really have no knowledge of how to tune them and optimise paging, indexes, execution plans etc, then you are probably not gaining anything. A framework is pretty ambiguous term, CFML is itself a framework, and if you have a set of standards for separating display, business logic and CRUDS, then you are are also creating a framework of sorts, more oft referred to as a methodology. Frameworks like ColdBox and Model-Glue are just taking it a step further by doing everything for you, defining a set of rules, adding some event handling and processing logic and a bunch of extra features and tools to make life easier for you. On Tue, Oct 23, 2012 at 2:55 PM, Shannon Rhodes <[email protected]>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:352980 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
