"Lastly, please, realise I am not trying to "shoot down" your suggestions / methodology," -- Understood.
It comes down to how large the app will be. If it's a few pages then your right, it does not matter. Where is starts to matter is as your app grows and you are larger and larger amounts of "business logic". - Where does that logic go? - The Service Layer. This service layer is where most of your important code ends up. By important, I mean the stuff that's going to end up in longer methods that do stuff with >1 object. Some methods are going to be kind of complex, some simple, but this "layer" is where your going to be spending most of your time coding and debugging. Your service layer starts to have lots of these methods. (as well as those pesky pass- though methods to gateways). I'm looking at a single service-layer class of 5k lines and I've probably got another 20 of them that are larger then that. If my service layer was worried about loading/saving objects and gateway methods, it would be 10 times as large. That hypothetical 50k class would be a lot harder to maintain & debug. (in fact, it would not compile) I'd waste a lot of time just scrolling through looking for the important stuff. Your queries are fairly standard/easy (compared to your business logic). There is no real value in the code and you can just code-gen them. They rarely need debugging/thinking about, when they do, they are usually fairly easy/obvious problems to fix just from the DB error messages. They are unimportant and therefore they can sit in the corner on their own :) 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 will probably benefit from watching some of the Google code videos like this one http://www.youtube.com/watch?v=wEhu57pih5w subject matter can be pretty heavy, but will open your eyes to the bigger picture. "" I am just saying, "Show me a definitive, real world example, where having the two separated has made a substantial impact on the delivery time of an application. Or show me an example whereby having them separated has had XXX positive effect "" I'm working on a app with many hundreds of thousands of lines of code, thousands of classes, etc - It does not use all the best oo principles, but it is still a hell of a lot maintainable then the alternative. We did need to switch our persistence framework out to cater for ORM (ie, from Transfer to ORM), a project that is part way through at the moment - we converted around 50 classes from transfer to ORM in a 2 developer week time period - and that's including testing. It's a fairly pain free project because we use basic OO principals. Your app might not be that big now, however if you start thinking in terms of OO design now your app will be in a better position to more maintainable as it grows larger and more importantly, it gives you experience with using common OO principles, so if/when you ever go onto a larger, OO based project, you will have already had experience with the basics. Good luck! On Jan 5, 9:23 am, Gavin Baumanis <beauecli...@gmail.com> wrote: > Hi Dave, > Thanks for the reply. > > I do however have some questions, in fact the same questions asked of me > when I first proposed the serviceCFC and DaoCFC approach to my colleagues. > > On 05/01/2012, at 6:45 AM, Dave wrote: > > > > > > > > > > > > > RE: DAO's. My approach is to define the DAO's responsibility as > > "mapping single objects to DB records." The service layer / managers > > should not know/care about how the objects get persisted/un-persisted > > (queries via the CFQuery Tag). Your DAO "layer" consist classes (one > > per object, eg, fooDAO) which contains methods like read(fooID), which > > returns a object of type foo, and save(foo), which figures out if we > > are doing an insert/update & persists the object. > > > The advantage of this approach is that when you feel comfortable with > > using ORM, you can change your entire code base to ORM simply by > > changing your DAO's & not having to change your entire service layer. > > > IE, under ORM, you still have a fooDAO.read(fooID) but instead of > > these methods calling cfQuery tags, they change to be calls to > > entityLoad("foo", arguments.fooID), the same applies to fooDAO.save(), > > which would call entitySave(arguments.foo). Your service layer still > > calls fooDAO.read(fooID), etc > > Regardless of what CFC your changing, > You still need to edit XX number of functions to now use entityLoad() / > entitySave() etc. > What have I "really" achieved by having the DAO separate from the service > layer, if it is merely the location of that code changed that is different? > > 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() > > And that is for every CRUD operation for every object. > That is a substantial amount of code duplication ... and while copy/paste | > code generation are your friends in this regard... > It still increasing the amount of code, the amount of unit tests I need to > write / maintain and the total lines of code that I need to wade through > for debugging / troubleshooting. > > It almost seems like "someone" at some point in time said; > "this is how to do OO application architecture for (insert some language > here... Java | Smalltalk | COBOL | C++ ..." > > And subsequently when CF MX came out... all the "classically" trained > developers chimed in with; > "Well you need to have a separate service layer to the gateway/DAO" > And because it was said - by someone that was respected... it must be > gospel, simply because that's how they did it with Java | Smalltalk .... > > It is worth noting, that CFBuilder's ORM object generator extension ONLY > creates; > object.cfc > objectService.cfc - there is no separated gateway/DAO. > > Now, I am not saying that you and everyone else that proclaims that having > a separate service CFC from the gateway/DAO are wrong. > I don't profess to know the answer - and thus the entire point of this > thread... > > I am just saying, "Show me a definitive, real world example, where having > the two separated has made a substantial impact on the delivery time of an > application. > Or show me an example whereby having them separated has had XXX positive > effect. > > Simply saying it should be this way, because a design pattern in the Gang > of Four's book says so... or because that's the way it is done in Java / > C++ and they're OO languages, so therefore it MUST be the way to do it in > dynamically typed CFML... I just don't buy it. > > I think that this ability, which is refereed to as "change an objects > > > internal implementation without changing it's external interface" is > > one of the real benefits of OO programming & is probably one of the > > skills/thought processes to learn first. > > > Think of your objects/classes as "black boxes" that operate on other > > objects. If you calling code has no knowledge of how these black > > boxes work, then it does not need to change when you decide to change > > the inner workings of the black boxes. IE, you can change code in one > > area without breaking other areas of your system. > > But I still have to change code "somewhere", right? > What difference does it make where I change it? > I wholly agree that maintaining the "public API" of the DAO can / does > limit the amount of code changes needed to be made elsewhere. > But because I have unit tests... finding those "other" spots is relative > easy. > > But as you mentioned in an earlier reply ... > Who ever really changes their DAO / persistence technology after an > application has been deployed? > So the main advantage of loosely coupling the DAO and objects, via the > service CFC, would seem to offer a limited "real world" benefit. > > It is also not lost on me what Dale asked in his earlier reply. > If the DAO is not returning the data in the appropriate format, why not > just change the returnType / structure of the DAO? > In my case, this application is relatively new so any code that replies on > the query object being returned could and probably should be changed to use > objects. > Otherwise further complications might arise later with respect to data > concurrency, particularly if we implement ORM and now have some stuff being > modified directly in SQL. > > Lastly, please, realise I am not trying to "shoot down" your suggestions / > methodology, I am just trying to "flesh out" how "I" am going to benefit > from the separation of the service and gateway/DAO CFCs. > > 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.
