I knew that voodoo doll would come in handy :-) On Tue, Oct 23, 2012 at 3:45 PM, Matt Quackenbush <[email protected]>wrote:
> > 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:352983 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
