Re: [cfaussie] Re: OO Application Architecture
Hehe. So Gavin, what you are saying is that you can create a CFC have the method named the same, same arguments and its duplicate code? Regardless that the meat and guts of the logic is not the same? Sorry that kinda doesn't sound like duplicate code to me :-) And your example shows that. And the thing to remember is that the actual DAO is returning a result, that by all intent and purposes is code reuse. For example cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... cfreturn gavinsDAOCFC.getGavinsObject(arg1 = #arguments.arg1#, arg2 = #arguments.arg2# /cffunction Gets the data from the database tier, but getGavinsObjectJson might make the same call to gavinsDAOCFC.getGavinsObject but instead convert the object to JSON before returning it. So technically there is no duplication of code, you have taken a call and separated for reuse by other logic within your code. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543 On Wed, Jan 11, 2012 at 5:44 PM, Gavin Baumanis beauecli...@gmail.comwrote: Technically? In the very initial post is this; But for the most part, my Service layer becomes a duplicate of the Gateway. * Ensure we have the required arguments for the gateway, * Call the gateway functions, using the supplied arguments * Return exactly the gateway's return value(s) to the consumer. I suppose it is close to implementing an interface in terms of the code that is required to successfully run an application using a service layer. If - you're using the service layer at it's simplest - proxying the DAO / gateway. And for the most part - that is 99.99% of what I have used a service layer for. So, since the function Name is the same, The arguments are named the same, The arguments are the same in number The arguments are the same in type... In fact I (previously) wrote the DAO by; Copy/pasting the the function from the serviceCFC Add the required SQL Alter as necessary the cfreturn code. So apart from the guts of the DAO method - the service CFC version was / is a duplication of code found in the DAO version. The intent / the purpose of the two, is clearly different but it IS technically a duplication of code. diff myServiceCFC, myDaoCFC even agrees with me. Gavin -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
With the greatest of reservations about feeding the trolls What alternate universe do you live in, Andrew? I clearly stated The intent of the two CFCs is different. and that for MY work - the ServiceCFC was all but, always an empty stub for the method in the DAO CFC. Given; SericeCFC 1 cffunction name=getStuff 2 cfargument name=name1 3 cfargument name=name2 4 cfargument name=name3 5 cfargument name=name4 6 cfargument name=name5 7 8 cfreturn DAO_CFC.getStuff(name1, name2, name3, name4, name5 9 /cffunction DAO_CFC 1 cffunction name=getStuff 2 cfargument name=name1 3 cfargument name=name2 4 cfargument name=name3 5 cfargument name=name4 6 cfargument name=name5 7 8 cfquery name=myQuery 9 SELECT * from #arguments,name1 where column1 = #arguments.name2 and column2 = #arguments.nam3# and column3=#arguments.name4# and column22 in (#arguments.name5#) 10 /cfquery 11 12 cfreturn myQuery 13 /cffunction Under what circumstances, on planet earth, is lines 1 through 7, in either CFC not a duplicate of the other? Whereby duplicate means; (according to *thefreedictionary.com* http://thefreedictionary.com/) *1. *Identically copied from an original. I even stated in my post that I created the DAO CFC by copy / pasting the code from the Service CFC. And included the caveat of; So apart from the guts of the DAO method And also provided the proof - that the application diff agreed with me. But alas, I forgot you know absolutely everything about everything and that you are never, ever, wrong. Obviously, I am wrong. As must be every file “diffing” tool in existence. Please accept my apology for not completely / wholly agreeing with you, instantly. I am not sure what came over me, I will never, ever doubt you or your stunning and dazzling ColdFusion brilliance, again. In Andrew Scott We Trust - because he says so. -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/7z5ENOHbIvMJ. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Gavin, Wait a minute, I wanted to confirm what you were defining as duplicate, personally I dont consider lines 1 - 7 duplicate because they are defining the method itself and what you need to pass, yes by definition you can make the assumption that because the method and arguments are the same they could be considered duplicate. But I wanted to ask because I also consider the code in the middle as part of the method as well. Don't get me wrong I can see what your saying, and yes I do disagree with it being duplicate in that case. I didn't want to tread on your toes, I just wanted to get a clearer picture on what you are talking about. Hell one could argue that every time I write, or copy the following line. cfquery name=result datasource=datasource Is duplicate because I copied and pasted it, by your definition. Sorry Gavin you fell into that one. But I still stand by the abstraction, service and gateway abstraction. The DAO is always a personal choice on whether you want to also go that route as well, I think if I read you right you have gone that route, and you maybe right in that you don't see a need in your current situation on whether you need the DAO route. Now without going into further arguments, you argument can also be applied to all OO principles as well, because if we extend an abstract component or even a normal component your lines 1 to 7 will have to be duplicated to keep the confusion to a minimum, and allow for the method to be overridden, and have the same arguments. So if you follow that rule of OO principle, would you take the same stance as it being duplicated if you want to change the behaviour of the abstract method? Which I guess I failed to convey across to you. I think if you watch the video by Bob Silverberg, it may make more sense to you. As he does also go into more refactoring off the code to keep all code to a minimum, while still allowing for OO principles to apply. A lot of the stuff can be moved to an abstract layer as he has indicated to reduce what you described, but you still risk the chance that you may need to override the abstract layer, so that the meat and bones of the method has different logic. And those lines 1 - 7 that you have listed as being duplicate are indeed a thing that we can't ignore from time to time, it just part of the design of our application. I think Bob explains this very well in the video, and does highlight what I was trying to convey. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543 On Thu, Jan 12, 2012 at 2:28 PM, Gavin Baumanis beauecli...@gmail.comwrote: With the greatest of reservations about feeding the trolls ** ** What alternate universe do you live in, Andrew? ** ** I clearly stated The intent of the two CFCs is different. and that for MY work - the ServiceCFC was all but, always an empty stub for the method in the DAO CFC. ** ** Given; ** ** SericeCFC 1 cffunction name=getStuff 2 cfargument name=name1 3 cfargument name=name2 4 cfargument name=name3 5 cfargument name=name4 6 cfargument name=name5 7 8 cfreturn DAO_CFC.getStuff(name1, name2, name3, name4, name5 9 /cffunction ** ** ** ** DAO_CFC 1 cffunction name=getStuff 2 cfargument name=name1 3 cfargument name=name2 4 cfargument name=name3 5 cfargument name=name4 6 cfargument name=name5 7 8 cfquery name=myQuery 9 SELECT * from #arguments,name1 where column1 = #arguments.name2 and column2 = #arguments.nam3# and column3=#arguments.name4# and column22 in (#arguments.name5#) 10 /cfquery 11 12 cfreturn myQuery 13 /cffunction ** ** Under what circumstances, on planet earth, is lines 1 through 7, in either CFC not a duplicate of the other? Whereby duplicate means; (according to *thefreedictionary.com* http://thefreedictionary.com/) *1. *Identically copied from an original. ** ** I even stated in my post that I created the DAO CFC by copy / pasting the code from the Service CFC. And included the caveat of; So apart from the guts of the DAO method And also provided the proof - that the application diff agreed with me.* *** ** ** But alas, I forgot you know absolutely everything about everything and that you are never, ever, wrong. Obviously, I am wrong. As must be every file “diffing” tool in existence. ** ** Please accept my apology for not completely / wholly agreeing with you, instantly. I am not sure what came over me, I will never, ever doubt you or your stunning and dazzling ColdFusion
Re: [cfaussie] Re: OO Application Architecture
Gavin, I am a little confused on the statement of Duplicate code? I am a strong believer that there should never be duplicated code, any chance you can whip up a quick example of what you mean by this. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543 On Wed, Jan 11, 2012 at 12:00 PM, Gavin Baumanis beauecli...@gmail.comwrote: Firstly, Thanks to everyone for replying. I realise, completely of my own creation, that readers might not be aware that I have any knowledge of OO conceots - or perhaps, no pracitcal experience, in the use of OOP. But this isn't the case. I recently transformed an application that was about 800,000 lines per installation (it was a bespoke application) into a single-sourced, multi-stacked application, using CF-ORM and it most certainly has a serivce layer and manager CFCs. I am certain that I convinced myself (by reading / learning, or someone telling me that the separation of DAO and the objects it gets / sets is an appropriate layer to have in an application. The purpose of the post, wasn't so much about what the theory is, or what it tells us... but whether or not actually served a practical purpose in real-world applications. My memory of the objectifiying of the old application was; The manager CFC pretty much / nearly always was simply a stub - interface like implementation of the methods in the DAO. That is to say - leaving aside the architectural benefits of creating a public API, The workload - involved in creating a service layer (whether copy/paste or generated or handwritten - was an awful lot of duplication, seemingly for the sake of duplication. I did - but it was rare - that the public API would differ from the DAO. The question asked of me, and ultimately, my question in this thread was; If it is nearly always a duplication of code - then why can't I simply have those specific few differences, catered for in the DAO - with an extra method there - instead of having a service layer? The answer might well come down to something like; Because it is such a well known architectural design choice, people simply expect an OO coded application to have one. And subsequently has become a standard. - Much like a framework... And to that, I would argue a framework doesn't really do anything for you - but ensure that you (and everyone else involved in the same application) always code in the same manner, and use the same architectural choices. For me - that is a good enough argument to use a framework - any and all other benefits a framework provides - is simply gravy in my mind. If the answer is similiar here, then so be it. I appreciate Mark's point that the if you implemenmt caching or someother thing then already having a service layer, assists you greatly. and if you're creating an app from scratch, then having the caching separate from the SQL (enititySave() etc ) is a good design choice too. For something simple, like a not-so regularly visited blog for instance - then I could sympathise with the argument that it is a lot of duplication - just because the OOP theory says it's a good idea to have a service layer. Don't shoot me - I am just the messenger! Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Sure thing. gavinsManagerCFC ... cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... cfreturn gavinsDAOCFC.getGavinsObject(arg1 = #arguments.arg1#, arg2 = #arguments.arg2# /cffunction gavinsDAOCFC ... cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... ... Some SQL WHERE column1 = #arguments.arg1# AND column2 = #arguments.arg2# return something (maybe) /cffunction In this case the getGavinsObject in gavinsManagerCFC is practically a stub / duplication of the function in the DAO. The argument is why bother? Why not just call the DAO version of the CFC and do away with the managerCFC entirely? Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/upAXP3qmn78J. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
AbstractBase classes and onMissingMethod... Mark On Wed, Jan 11, 2012 at 3:15 PM, Gavin Baumanis beauecli...@gmail.comwrote: Sure thing. gavinsManagerCFC ... cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... cfreturn gavinsDAOCFC.getGavinsObject(arg1 = #arguments.arg1#, arg2 = #arguments.arg2# /cffunction gavinsDAOCFC ... cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... ... Some SQL WHERE column1 = #arguments.arg1# AND column2 = #arguments.arg2# return something (maybe) /cffunction In this case the getGavinsObject in gavinsManagerCFC is practically a stub / duplication of the function in the DAO. The argument is why bother? Why not just call the DAO version of the CFC and do away with the managerCFC entirely? Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/upAXP3qmn78J. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- E: mark.man...@gmail.com T: http://www.twitter.com/neurotic W: www.compoundtheory.com 2 Devs from Down Under Podcast http://www.2ddu.com/ -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Hi Mark, I realise you mentioned this already in this same thread... But I think the penny has finally dropped. By using onMissingMethod, you only need to write the code in the ManagerCFC that is actually different from the method in the DAO. Embarassingly, I have even used onMissingMethod in exactly the same way - while playing around with RocketBoots' Galaxy SOA CFC last year... So, there is no duplicate code argument to be had here. Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/spBU7eoUpzQJ. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Yup - And to make things 3x as fun, using something like: https://github.com/markmandel/coldspring/blob/develop/coldspring/orm/hibernate/AbstractGateway.cfc To generate most of your basic DAO/Gateway methods using onMissingMethod as well, you barely have to write anything at all. Mark On Wed, Jan 11, 2012 at 3:27 PM, Gavin Baumanis beauecli...@gmail.comwrote: Hi Mark, I realise you mentioned this already in this same thread... But I think the penny has finally dropped. By using onMissingMethod, you only need to write the code in the ManagerCFC that is actually different from the method in the DAO. Embarassingly, I have even used onMissingMethod in exactly the same way - while playing around with RocketBoots' Galaxy SOA CFC last year... So, there is no duplicate code argument to be had here. Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/spBU7eoUpzQJ. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- E: mark.man...@gmail.com T: http://www.twitter.com/neurotic W: www.compoundtheory.com 2 Devs from Down Under Podcast http://www.2ddu.com/ -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Nice - I'll have to have a play with that! -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/G517Cd6kjSQJ. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Technically this is not a duplicate of Code, because you are separating the database away from the service/business logic. This means that if you go from transfer/reactor over to CF-ORM you are essentially just removing that tier and replacing it. And it also promotes code reuse of the database tier. Because you may have logic in your service layer to do something different with the results, in more than one case of logic. But the code to return the result doesn't change. So there is potentially two things you are doing, re-use of code and easy abstraction and removal if the need ever arises for something better. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543 On Wed, Jan 11, 2012 at 3:15 PM, Gavin Baumanis beauecli...@gmail.comwrote: Sure thing. gavinsManagerCFC ... cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... cfreturn gavinsDAOCFC.getGavinsObject(arg1 = #arguments.arg1#, arg2 = #arguments.arg2# /cffunction gavinsDAOCFC ... cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... ... Some SQL WHERE column1 = #arguments.arg1# AND column2 = #arguments.arg2# return something (maybe) /cffunction In this case the getGavinsObject in gavinsManagerCFC is practically a stub / duplication of the function in the DAO. The argument is why bother? Why not just call the DAO version of the CFC and do away with the managerCFC entirely? Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
On 11/01/2012, at 3:53 PM, Andrew Scott andr...@andyscott.id.au wrote: Technically this is not a duplicate of Code, Yeah it's more 'boileplate' I guess? -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Technically? In the very initial post is this; But for the most part, my Service layer becomes a duplicate of the Gateway. * Ensure we have the required arguments for the gateway, * Call the gateway functions, using the supplied arguments * Return exactly the gateway's return value(s) to the consumer. I suppose it is close to implementing an interface in terms of the code that is required to successfully run an application using a service layer. If - you're using the service layer at it's simplest - proxying the DAO / gateway. And for the most part - that is 99.99% of what I have used a service layer for. So, since the function Name is the same, The arguments are named the same, The arguments are the same in number The arguments are the same in type... In fact I (previously) wrote the DAO by; Copy/pasting the the function from the serviceCFC Add the required SQL Alter as necessary the cfreturn code. So apart from the guts of the DAO method - the service CFC version was / is a duplication of code found in the DAO version. The intent / the purpose of the two, is clearly different but it IS technically a duplication of code. diff myServiceCFC, myDaoCFC even agrees with me. Gavin On Wednesday, January 11, 2012 3:52:18 PM UTC+11, Andrew Scott wrote: Technically this is not a duplicate of Code, On Wed, Jan 11, 2012 at 3:15 PM, Gavin Baumanis beaue...@gmail.comwrote: Sure thing. gavinsManagerCFC ... cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... cfreturn gavinsDAOCFC.getGavinsObject(arg1 = #arguments.arg1#, arg2 = #arguments.arg2# /cffunction gavinsDAOCFC ... cffunction name=getgavinsObject cfargument name = ag1 required=true... cfargument name = ag2 required=true... ... Some SQL WHERE column1 = #arguments.arg1# AND column2 = #arguments.arg2# return something (maybe) /cffunction In this case the getGavinsObject in gavinsManagerCFC is practically a stub / duplication of the function in the DAO. The argument is why bother? Why not just call the DAO version of the CFC and do away with the managerCFC entirely? Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/1FNtazDXDp4J. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Why not use onMissingMethod and Abstract Classes to proxy service calls down to the gateway, and that takes away 95% of the work? (real world statistic) Mark On Thu, Jan 5, 2012 at 9:23 AM, Gavin Baumanis beauecli...@gmail.comwrote: Also, by having the service layer as well, I am now creating an awful lot of duplicate code. I now must have; serviceLayerCFC.getMyObject() AND daoCFC.getMyObject() -- E: mark.man...@gmail.com T: http://www.twitter.com/neurotic W: www.compoundtheory.com 2 Devs from Down Under Podcast http://www.2ddu.com/ -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Hi Mark, OK. By implementing onMissingMethod - I have saved some (perhaps, nearly all) of the extra typing... But the extra layer is still in my application. And now it's a little less apparent than actually having the extra code actually written in the service CFCs. While I realise you're specifically speaking to my complaint of duplicate code... I'm still skeptical - as to the requirement of having the separation in the first place. Where's the smoking gun? I'm genuinely not tying to be argumentative for the sake of being argumentative - But simply taking it on faith, because everyone says so, isn't cutting the mustard for me at the moment. Gavin. On Thursday, January 5, 2012 9:39:54 AM UTC+11, Mark Mandel wrote: Why not use onMissingMethod and Abstract Classes to proxy service calls down to the gateway, and that takes away 95% of the work? (real world statistic) Mark -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/RY-anMgSNdwJ. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Re: OO Application Architecture
Gavin, I will second what Dave is saying below.. The mind set is not to continue to believe that procedural is the key to everything, but to begin to understand that the patterns have and where designed to introduce code separation in its many forms, for a stronger purpose in life. By taking code and placing them into Service layers, and DAO's and beans etc you are then basically saying that I am separating the business logic and database code. This promotes stronger code re-use above all else, and encourages people to think harder about the needs of their objects, especially when it comes to the likes of Database Objects. You began to argue that the only need would be to have a tier layer that could just be switched out at will, if the need arises and is sort of an example that can be applied, as you have stated. By switching from say reactor, or transfor over to hibernate does become a lot easier. But the bigger picture is you are defining straight away that you are going to be promoting code re-use. For example you would design and implement a section of code, lets say a forum to your application. You would tend to keep that as tightly integrated to itself as possible. This would mean that you could just pull this out and replace this at will, because you have defined an API that allows you do so. Sure you would need to make some changes to incorporate the new forum that you might like to replace it with, but that would be minimal because you have kept that layer separate. OO and patterns is no different in thinking than that, ColdFusion makes it hard to think like this because it is procedural right from the word go. It takes a stronger mind to see that the patterns have been introduced to provide easier testing, debugging, and most importantly stronger code re-use. Something that 99% of people tend to not see. -- Regards, Andrew Scott WebSite: http://www.andyscott.id.au/ Google+: http://plus.google.com/108193156965451149543 On Thu, Jan 5, 2012 at 10:29 AM, Dave davidame...@gmail.com wrote: As you have noted, non-OO code works too :) - The real benefit of OO code is that it makes the application more maintainable (cheaper to own/run), hopefully reducing bugs in the process. - Yes, it comes at the expense of having to write more code up front, but you get used to that and find techniques to make that easier. - There are good code gen's out there for CF, or you can roll your own to suit your needs - the default builder one isn't great. You can also use techniques like Mark's onMissingMethod below to reduce typing. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
RE: [cfaussie] Re: OO Application Architecture
I could argue that the DAO which gets data should return data in the appropriate format. If the DAO doesn't return data in the necessary format then what is the reason for it returning data in the wrong format. Regards Dale Fraser http://dale.fraser.id.au http://cfmldocs.com http://learncf.com http://flexcf.com From: cfaussie@googlegroups.com [mailto:cfaussie@googlegroups.com] On Behalf Of Gavin Baumanis Sent: Wednesday, 4 January 2012 4:16 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: OO Application Architecture It's kind of funny - but just after having writtemn the initial post I was doing some work that was perfect for a service ayer / manager CFC. Although very new, the DAO object was alrready in use, but was returning queries. Problem for me was; I wanted to do my new work using objects. (The greater view, to perhaps implementing ORM eventually... so working with objects for the new work seemed sensible.) So, I now have in my manager CFC, a method that returns an object populated from calling the underlying DAO getter. I certainly could have made the change in the DAO, and had it return an object instead of a query... But... while I am not sure how common it is - I can drop back (easily) to the original query if needed, this way, too. (to perform a query of queries perhaps?) Also, in this instance, (the new work is relatively small in the number of object types required) - so I can certainly see the value in using the same manager CFC for the few objects / tables that we have deal with. So - I think I have just talked myself back into using them again... Sheesh - I might need an afternoon lie-down Gavin. -- You received this message because you are subscribed to the Google Groups cfaussie group. To view this discussion on the web visit https://groups.google.com/d/msg/cfaussie/-/Xx9BamB2AgQJ. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
