Re: Inline logic vs CFC vs SP
I put all interaction with the database in CFCs, with each action happening once so that the same result always comes back regardless of where the logic for the database activity is needed. If you write, test and debug these CFCs as an early step in your project, downstream development that uses them becomes much more efficient. Once your CFCs are written and tested all programmers should be required to use them. It saves much time and trouble if everyone is interacting with the database exactly the same. I use one CFC for each data table, with the same name as the table. It includes all the selects, gets, sets, puts and initialization for the object. If the data table contains foreign key fields, I will do a select in the CFC that joins the foreign key to the appropriate table and returns all the information necessary for display in a structure. Each CFC extends DATAMANAGER.CFC which is a custom CFC that controls the DSN being used, confirms permissions, cleans data being sent to the database to trap any hacker attacks, manages failed transactions, logs the result of any catch-try failures, etc. This allows all my error management and logging to happen in one place. I only use stored procedures for complex database interactions or handling massive amounts of data that will run faster on the database than doing the calculation and logic with CFML, and I call them from the CFC for the related table so that I can use the DATAMANAGER.CFC as above. Again, this allows me to have total control over the call to the database, and always returns the same result regardless of where the stored proc is needed in the business or display logic. I never put queries in CFM pages or any display pages because I want the code where I can find it readily and if the database changes I only have to make those changes in one place. Frankly I just don't think database interaction belongs with the business and display logic. I do occasionally put a query of queries in CFM pages to re-sort or sub-select data items for display. On Tue, Oct 23, 2012 at 6:55 AM, Shannon Rhodes 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. > ...(snip) > > 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:352986 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Inline logic vs CFC vs SP
> > 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 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 >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 SharePoi
Re: Inline logic vs CFC vs SP
Heh. :-) On Tue, Oct 23, 2012 at 9:51 AM, Russ Michaels wrote: > > I knew that voodoo doll would come in handy :-) > > On Tue, Oct 23, 2012 at 3:45 PM, Matt Quackenbush >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 > > 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...in
Re: Inline logic vs CFC vs SP
I knew that voodoo doll would come in handy :-) On Tue, Oct 23, 2012 at 3:45 PM, Matt Quackenbush 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 > 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 > >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 Anth
Re: Inline logic vs CFC vs SP
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 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 >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
Re: Inline logic vs CFC vs SP
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 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
Re: Inline logic vs CFC vs SP
It's all about encapsulation. Code should be written in one place, and one place only. If you have the same code in two places, something is wrong. CFCs - which are objects in the CFML world - are all about encapsulation. CFCs FTW! Is that to say that CFMs can't be "encapsulated"? No. With very careful coding and strict architecture in place, CFMs can, in theory, be encapsulated. But they are not, technically speaking, encapsulated, and open up many opportunities for code smell and duplicate code to enter into your application. I personally am not even remotely a fan of stored procedures. You've already enumerated several of the arguments against them. But the bottom line is portability. I am a firm believer in a portable code base, and therefore don't use stored procedures. In the simplest of terms: - controller-level code goes in CFCs (very light/thin, "traffic cop" only) - service/DAO/model-level code goes in CFCs (very robust, intelligent, virtually all logic) - display/view-level code goes in CFMs (very light/thin, displays data and data collection - no business rules/logic) HTH On Tue, Oct 23, 2012 at 8:55 AM, Shannon Rhodes 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:352978 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Inline logic vs CFC vs SP
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:352977 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
