cfObjective(): Common Sense Approach to Object Orientated Coldfusion, 2010 Ed. with Brian Meloche

I was unsure of what to expect at this presentation. But I agreed with Brian on a lot of how Object Orientation in Coldfusion has become over complicated when developing Coldfusion is supposed to be simpler.

• Pre-MX Coldfusion
  • Though OO Coldfusion didn't become popular until components, you could do using custom tags since CF 4 with some issues, Remember Spectra?
  • You'd typically write CF apps old school. Procedurally
  • Many CF developers still build apps this way today
  • Many more still build procedural
  • Before MX you started seeing procedural MVC promoted mostly within the FuseBox community
• Modern OO CF
  • Mach-ii was the first modern framework written for OO CF (2003)
  • Soon
    • Model-Glue
    • Coldbox
    • Fusebox
    • Coldfusion on Wheels
  • Controller/view Based
  • Steeper learning curve
• We need design patterns
  • As we started building model, we started seeing accepted ways to build model we need:
    • Beans
    • DAOs
    • Gateways
    • Services
    • Value Objects
    • Validators
  • As our apps got more complex, we needed more design patterns:
    • Singletons
    • Object factories
    • Dependencey injection
    • Inversion of control
    • Coldspring, Lightwire
• OO Coldfusion
  • Coldspring both simplified code, and added additional complexities to learn
  • Models grew...we need something to manage all this data
  • ORM! Reactor, transfer
  • That's not to say that you need these frameworks to develop OO CF; all are optional.
• Modern OO CF - The Good and the bad
  • Good:
    • Modular code
    • Separation of business logic, data & presentation
    • Easier to maintain as apps grow
    • Encapsulate logic
    • Reduces the dependences
    • Predictable way of building apps
    • Code generates: illudium, IDEs to generate CFCs CAN* help speed up development
  • Bad (in currently accepted OO CF Practices)
    • Adds a pretty steep learning curve over old school CF
    • Greatly increases the amount of code needed
    • Takes longer to develop (even with shortcuts)
    • One small change could require changes in for or five files
    • Frameworks have:
      • Performance issues
      • Instantiation Times
      • Memory Requirements
      • Some or all of above
    • Beware of code generators!
      • Tables = objects (a table is not an object)
      • Beware of anti-patterns!!! Can over complexify the model
• Lightfront, lightfront.riaforge.org