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
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 shan...@rhodesedge.comwrote: 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
Re: cfm files bypass permissions -- htm files get 401 unauthorized
Well! I'm going down the rabbit hold of unreality here ... I experimented, and havent got any closer to a solution: - With all groups removed, I could _not_ get to the .cfm file (as expected) - With only Administrators group, I could get to the .cfm file, and it noted I was logged in with my regular account not my privileged Administrators account. - With IUSR account set to DENY, I could get to the .cfm file. - Removed SYSTEM account, which ColdFusion uses, and could still get in. Its looking more and more like theres something screwy with IE and the PIV card login (PIV is our gov't chipped smart card for auto login). - IE still lets me in even after a full IE reset and SSL clear state and close all IE instances then reopen. This problem exists only with IE (Firefox is okay). I've tried IE reset, clear SSL state. Thanks for the ideas Russ. Chris On Mon, Oct 22, 2012 at 6:11 PM, Russ Michaels r...@michaels.me.uk wrote: in IIS the directory security should have only 1 box checked integrated windows authentication. This is all I have set on our servers to deny anonymous access to the cfadmin for example and it works.. You could try also specifically DENYING the internet guest account (IUSR_machine name) On Mon, Oct 22, 2012 at 10:50 PM, Chris 0404tow...@gmail.com wrote: Hi Russ, The folder's permissions are: Administrators (Full control) - my regular account is not privileged, and I have a privileged account that does let me in through this group. System (Full) - CF runs as the Local System account WorkstationAdmin (Modify) - domain account, the only group that should have access. I'm not in this group. The folder has Anonymous Login disabled, and Windows Authentication enabled. The server has an SSL certificate, and we are accessing through https. Interesting comments about CF bypassing folder permissions -- I thought first the HTTP request had to access the file through the web server, and then the web server would send the file to CF for processing. Many thanks! Chris On Fri, Oct 19, 2012 at 6:29 PM, Russ Michaels r...@michaels.me.uk wrote: What are the actual permissions you have on the folder? Regards Russ Michaels ~| 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:352979 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 shan...@rhodesedge.comwrote: 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
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:352981 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cfm files bypass permissions -- htm files get 401 unauthorized
the thing is that IE cannot get past permissions, unless you have it running as administrator or some other privileged user and that user has permissions on the server running CF. create a user called COLDFUSION and run cf as that user instead of system and see if that helps. You will need to give that user full permissions on the COLDFUSION install folder and the website root, and system temp folders. On Tue, Oct 23, 2012 at 3:31 PM, Chris 0404tow...@gmail.com wrote: Well! I'm going down the rabbit hold of unreality here ... I experimented, and havent got any closer to a solution: - With all groups removed, I could _not_ get to the .cfm file (as expected) - With only Administrators group, I could get to the .cfm file, and it noted I was logged in with my regular account not my privileged Administrators account. - With IUSR account set to DENY, I could get to the .cfm file. - Removed SYSTEM account, which ColdFusion uses, and could still get in. Its looking more and more like theres something screwy with IE and the PIV card login (PIV is our gov't chipped smart card for auto login). - IE still lets me in even after a full IE reset and SSL clear state and close all IE instances then reopen. This problem exists only with IE (Firefox is okay). I've tried IE reset, clear SSL state. Thanks for the ideas Russ. Chris On Mon, Oct 22, 2012 at 6:11 PM, Russ Michaels r...@michaels.me.uk wrote: in IIS the directory security should have only 1 box checked integrated windows authentication. This is all I have set on our servers to deny anonymous access to the cfadmin for example and it works.. You could try also specifically DENYING the internet guest account (IUSR_machine name) On Mon, Oct 22, 2012 at 10:50 PM, Chris 0404tow...@gmail.com wrote: Hi Russ, The folder's permissions are: Administrators (Full control) - my regular account is not privileged, and I have a privileged account that does let me in through this group. System (Full) - CF runs as the Local System account WorkstationAdmin (Modify) - domain account, the only group that should have access. I'm not in this group. The folder has Anonymous Login disabled, and Windows Authentication enabled. The server has an SSL certificate, and we are accessing through https. Interesting comments about CF bypassing folder permissions -- I thought first the HTTP request had to access the file through the web server, and then the web server would send the file to CF for processing. Many thanks! Chris On Fri, Oct 19, 2012 at 6:29 PM, Russ Michaels r...@michaels.me.uk wrote: What are the actual permissions you have on the folder? Regards Russ Michaels ~| 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:352982 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 knew that voodoo doll would come in handy :-) On Tue, Oct 23, 2012 at 3:45 PM, Matt Quackenbush quackfu...@gmail.comwrote: 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:352983
Re: Inline logic vs CFC vs SP
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.
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 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
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 shan...@rhodesedge.comwrote: 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
