> > 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.
1++ I can attest to this. I work with apps where *everything* are in SP's and they are a total PITA maintenance wise. Any changes to the database have to be changed in two (or often more) places. Every try to hunt down instances of a table or column in a slew of SP's? No fun at all. I have had some changes that would normally take an hour or two turn into all day affairs. So I am with Matt, not a fan of stored procedures. They have their place but often just add needless complexity. I am also partial to the black box approach when dealing with data. I am also a big fan of machine generated code for CRUDs, service layers, ORM's and the like. It should not matter where the data comes from. When done right, you could swap out your entire data layer from a database to web services and the rest of your app would be none the wiser. Again, like Matt said. Portability. My $0.02 and worth every penny. G! On Tue, Oct 23, 2012 at 10: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:352985 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
