Heh. :-) On Tue, Oct 23, 2012 at 9:51 AM, Russ Michaels <r...@michaels.me.uk> wrote:
> > I knew that voodoo doll would come in handy :-) > > On Tue, Oct 23, 2012 at 3:45 PM, Matt Quackenbush <quackfu...@gmail.com > >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 <r...@michaels.me.uk> > > 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 < > 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:352984 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
