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.com>wrote: > 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.
