Nov
17
Thanks for those that were able to make to last night's ColdFusion and Object Oriented Programming II talk at the Central PA CFUG meeting. Specially those that drove through the storm and flooded streets!
I'll be posting the presentation slides along with the code later on today. Also stay tuned for the recorded Breeze/Connecto(urgh!) presentation once we have the url.
If you have any questions about the presentation or anything we covered, please feel free to post a comment here and I'll promise to answer asap.
Download the presentation sample oo code here or in the "Download" button below.
View the presentation here.
Phill Nacelli has been developing software for over 9 years, and have been using ColdFusion since version 4.5. He has engineered and developed multiple web based applications for the federal government, non-profit association/education market and enjoys playing with the latest in programming techniques, frameworks and development tools. He currently holds a position as Software Architect at 
There is the presentation. I hope it stays at the URL, but let me know. Thanks so much again. I've watched the presentation once through (skipping a few parts). I'll probably look at again just to pick up a few things.
Can't wait for Flex training!
I think next time we'll probably leave intros up to just the speakers:)
Thanks for the link! Once again, thank you for having us.
Phill
The ObjectFactory in the application was created recently, I'm planning on blogging on it this week, meanwhile, feel free to shoot any questions you have.
Cheers...
What do you do when you've separated out your model into a bean, DAO, and gateway? Your example has the bean and DAO in one uber component.
Also, is this compatible with a service layer object?
As far as whether it's compatible with a service layer object, in my experience the service layer object basically can have any level of knowledge of other objects in order to accomplish its tasks. Whether the DAO is in the bean or not, it's just a matter of it either instantiating the bean and calling the bean.read() or additionally have a singleton DAO object that it knows to pass the bean into to call beanDAO.read(bean).
Cheers..
(<cfargument name="datasource" type="nep.CommonLib.Datasource" required="yes" hint="value of datasource" />)
Your model should not change from one environment to the next. I normally arrange my model in the same manner from one application to another in a way that makes the application as portable and easy to install as possible. For example; take a sample application named "foo". I create a folder called "foo" that will preferrably be installed in the web root folder (if not, I can still run my model via cf mapping - more on that later). In there I have all my cfc object inside a folder named "com" (some folks use "cfc" as well). So take the datasource object, place it in /foo/com/commonLib/ folder, the mapping will always be foo.com.commonLib.Datasource regardless if it sits on my Development, Staging or Production environment.
I really enjoyed the OOP presentation. Helped to consolidate some of the concepts I have been studying recently.
Regarding the whole to DAO or not to DAO, one thing that you didn't mention here or during the presentation is the potential memory saving.
I say this because when the DAO is seperate you can persist it as a singleton. Therefore it is only called once at startup, taking up a small area of memory. You can then pass the bean into this instance as required.
If the DAO is part of the bean, then each time it is instantiated a greater area of memory will be taken up (bean methods + DAO methods). As the bean will be instatiated many times and can't be a singleton, in a very big site this may start having an effect on memory usage / performance.
Now of course this may not effect things until a site grew to huge levels, but I kind of feel that it would be tighter to seperate out code which can be a singleton as much as possible, rather than including it all in an object which will be repeated many times during the life of an application.
Does this make sense? I'm still very new to this and may have missed something.. ;)
That's a great point, and one of the many reasons why I personally recommend doing this. This issue is where Nic Tunney and I differ and in the end we decided to make the Intro to OO presentation a bit simpler by making the object persist itself. However. Another off course is that you can build a more database agnostic application by having multiple DAOs that fit whatever different types of DB systems and have a DAO Factory return which one you need. I'll be touching this on my Intro to OO concepts presentation at CFUnited. More on that later...
Cheers..
The ability to easily change the underlying database engine is a benefit, although I also quite like the flexibility this approaches provides for quickly testing out different data access methods. I.E I could quickly create a copy of the existing DAO, change some parts of it to test a concept (or to quickly fix an issue regarding a database call - filtering etc) without having to touch the main bean. I could then easily switch back to the old DAO if required.
I love the idea of DAO factory - this add's another level of flexiblity to a complex application.
Will your CFUnited presentation be available online after the event? Looking forward to hearing more of your OOP teachings.