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.
Dave wrote: > I just saw this on another group - > > http://www.silverwareconsulting.com/index.cfm/2009/5/31/Building-An-Object-Oriented-Model--Recording-and-Sample-Code-Available > > is a presentation that gives you a great overview of OO in cf. > > On Jan 4, 11:46 am, Gavin Baumanis <beaue...@gmail.com> wrote: > > Hi Everyone, > > > > I was recently chatting at work about how we might go about architecting > a > > new application. > > I suggested that we have; > > Objects, > > Service Managers > > and Gateways. > > > > Whereby the ServiceManager is the public API for the gateway. > > > > Then I got asked , "Why?" > > > > I explained that it was good practice to separate out the plublic API > from > > the gateway and gave the example of changing database providers. > > Eg. Swapping from MS-SQL server to PostGreSQL. > > > > With my architecture proposal, you only need to change the gateway > (perhaps > > some minor tweaks to the ServiceManager CFCs. > > > > So far so goo... Until I got asked "Why" again. > > "You still need to change the code somewhere for the new database > flavour. > > What is the ServiceManager doing for us, it seems like a redundant > > duplication of code?" > > > > Subsequently, I have been thinking about it more - and can't come up > with a > > good reason. > > > > I could be doing it completely wrong... > > 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. > > > > 99.9% of the time the arguments are exactly the same, > > The data / structure (whatever) that is returned from the gateway, is > > returned unaltered to the consumer, too. > > For the very small number of times that I might do some data > transformation > > (in the ServiceManager) before it is returned... well I could simply > create > > "THAT" method in my gateway and have; > > * Call the this.GETTER method > > * Transform the data as required > > * Return the transformed data > > > > So am I missing something? Or have I just talked myself out of the > > requirement for (perhaps, excluding web-services) of ever needing to > have a > > separate service layer to a Gateway CFC? > > > > 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/-/DdOREkJvlOEJ. 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.
