Couldn't you just use SSL or are you storing the data encrypted in a column?
"This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com -----Original Message----- From: Robert Rawlins - Think Blue To: CF-Talk Sent: Mon Jun 04 10:56:03 2007 Subject: RE: Choosing an ORM Yeah, Basically just a standard encrypt()/decrypt() on the data as it passes in and out of the database. But rather than hard coding the key into a CFM file and storing it in Application.EncKey I was thinking about encapsulating it in its own object, makes life simple as I can have it injected as a constructor into my DAO's for when the public/pull data from the database. Location: West Sussex. Thanks Neil, Rob -----Original Message----- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: 04 June 2007 10:43 To: CF-Talk Subject: RE: Choosing an ORM No worries, Yeah, if you are working on large imports/data management then I would look at using SP's/DTS/SSIS but I would no doubt trigger them asynchronous as well and I would probably not use the web to control the jobs outcome (as in a job completion notification) as long running requests like that as a bitch to handle and are wasted resources unless you have a dedicated instance doing all that legwork etc. You want to encrypt all of your data in and out of your app? Location: London. -----Original Message----- From: Robert Rawlins - Think Blue [mailto:[EMAIL PROTECTED] Sent: 04 June 2007 10:26 To: CF-Talk Subject: RE: Choosing an ORM Cheers Neil, Yeah I agree there are some issues with stored procs, but things like caching are something I don't really have to deal with in this application, the site isn't public facing and the majority of the data within the app needs to be 'real-time' so we tend not to cache. However, that IS an exciting feature in Scorpio, can't wait to upgrade :-) I know that debugging and things can be a bit of a hassle, but generally all the queries are written in CF as a proof of concept first, once we have a working model then we'll migrate them over to stored procs for the production version. Also a large amount of our more complex queries are for data imports and moving large amount of data around, so being able to have SQL server do all the donkey work is a god send. I've not done much testing on performance myself but I like the concept of the separation using them gives and if we get boosted performance as a result then that's just a fringe benefit. The other benefit of the stored proc method is portability of the database, There is a possibility that in the future we'll have to bolt on some more JAVA based apps to the server and if we can have them share the same query set without having to rewrite it all, then that'd be nice too. Any ideas on that encryption stuff? I'm trying to figure out the best way to implement it, I'm almost 100% convinced giving it a class makes sense, especially if working with a factory, I can define my key in the XML and have it inject an instance into all my DAO's with the minimum of hassle. Thanks again mate, where abouts in the world are you sending from? By the way you spell 'arse' I'm guessing you're a fellow UK resident. Rob -----Original Message----- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: 04 June 2007 10:00 To: CF-Talk Subject: RE: Choosing an ORM >From experience, it can be a easy to choose SP's for their "speed", but I have found that cfquery can perform just as well, and even better in some cases. Sure you get the multiple recordset ability with an SP but unless you are using CF8 you still cannot cache results - unless you roll your own mechanism which is an arse. They are also harder to debug but that is no doubt something you know and can live with! I would use them but I would think about using them sparingly and if you can to use an ORM - don't us them at all. -----Original Message----- From: Robert Rawlins - Think Blue [mailto:[EMAIL PROTECTED] Sent: 04 June 2007 09:47 To: CF-Talk Subject: RE: Choosing an ORM Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob -----Original Message----- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, >From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table. It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N -----Original Message----- From: Robert Rawlins - Think Blue [mailto:[EMAIL PROTECTED] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Upgrade to Adobe ColdFusion MX7 The most significant release in over 10 years. Upgrade & see new features. http://www.adobe.com/products/coldfusion?sdid=RVJR Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:279980 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
