I think the Mayans were right. The world _has to be_ ending in 2012, because I am yet again agreeing completely with Russ Michaels! :-)
Great post, Russ. On Tue, Oct 23, 2012 at 9:42 AM, Russ Michaels <[email protected]> wrote: > > 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:352981 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
