how about something simple but widespread? keep it procedural and move as much processing as possible into functions within CFC's. Don't bother thinking they're objects yet, just collections of functions.
Try and group like-functionality together, esp the 1001 queries that do essentially the same thing. keep your CFM pages and ensure they only do data capture (eg form submits) and display. data capture is sent to CFC's for processing, data to display is that will force you to - evaluate where the repeated code/processing is - define in stone the API's as the bits go together - smaller and smaller atomic actions (down to simple defined functionality) - larger and larger abstractions (a "saveX" may be one call as seen from the CFM page) - see that different functionality can be grouped together and related to a specific entity. - see if cut down on the amount of createObject()'s (eg: create a CFC in the CFM once, use 10 times, not create CFC 10 times) it's a rough way of doing it, but you can do it just by refactoring existing working code, testing as you go to prove the API's work for each functionality and the same result is achieved. once you have everything in CFC's and CFM's you can then think about dividing them up into the M,V and C parts... meh, just an idea. On Wed, Feb 4, 2009 at 3:35 PM, Matthew <[email protected]> wrote: > > @Jared: thanks for the tips. I am on CF7. I'm not too keen on the idea > of introducing FB (one immediate concern is that there would be so > many URL to re-write [which I know could be handled in CF or via > something like Isapi ReWrite but this introduces another job]). My > main reason for migrating to OOP are the obvious reusability and > scalability. Currently the app has a lot of duplicate queries, > procedures so when you change something in one area if you don't know > the app the other area will remain unchanged and wrong. I feel that > once an OOP MODEL layer is in place (with a simple listener layer > talking to the model layer) it will be much easier one day to > introduce a framework. > > Anyone else got 2 cents to throw in? > > Cheers > Matthew > > > On Feb 4, 3:55 pm, Jared Rypka-Hauer <[email protected]> wrote: >> Matthew, >> >> I'm only guessing here, but it doesn't sound like you have ColdFusion >> 8 running on your server. If that's incorrect, well, the answers get >> even easier! :) >> >> If I were you I'd create a separate development environment, move the >> site into Fusebox, deploy the frameworked version (with either an >> ISAPI URL rewriter or onRequestStart(), onRequest() and >> onMissingTemplate()), and then start messing with the model. OOP isn't >> as important as encapsulation and cohesion which can be done even with >> an essentially procedural framework like Fusebox. >> >> Moving a procedural app to Fusebox isn't all that hard, really (you're >> just chopping your cfm files into smaller chunks and wiring them >> together with the config file), and it's a lot easier and faster than >> moving from procedural to OO. If you want OO, do it only after you've >> gotten the rest of the site under control, otherwise you're really >> only making a big problem into a huge problem. >> >> Your best friends in this case will be: >> >> Application.cfc for the sake of: >> >> onApplicationStart() to load up the application scope (which you're >> already doing but onApplicationStart() is so tidy) >> >> onRequestStart() and onMissingTemplate() to route requests for the old >> filenames to Fusebox fuseactions... also could be a great place to use >> mod_rewrite or the IIS equivalent >> >> onSessionStart() for doing <cfset session.cart = >> createObject(...).init() /> >> >> onSessionEnd() for saving unfinished cart info to a DB for later (what >> you might call a "value added feature" because it's fairly simple and >> bring a lotta bang) >> >> Many huge performance and code updates. >> >> So, to recap: >> a) switch the application over to Application.cfc. You _are_ running >> at least ColdFusion 7, right? >> a.1) Upgrade the site to CF 8 >> >> b) use onSessionStart() in Application.cfc, create a cart object in >> the session using createObject(). >> b.1) If CF8 is not available and is out of the question, change jobs. >> Err, I mean do >> >> <cfif not structKeyExists(session,"cart")> >> <cflock scope="session" type="exclusive" timeout="10> >> <cfif not structKeyExists(session,"cart")> >> <cfset session.cart = createObject(...).init() /> >> </cfif> >> </cflock> >> </cfif> >> >> c) Move the site to fusebox to get the architecture under control and >> THEN start messing with the implementation. >> >> Just my advice, YMMV. :) >> >> J >> >> On Feb 3, 2009, at 10:37 PM, Matthew wrote: >> >> >> >> > Hi guys >> >> > I'm retro fitting a spaghetti code application to OOP. I'm doing it a >> > piece at a time (as I work on a section of the website I take some >> > extra time to migrate it to OOP). Because I'm slowly doing it I can't >> > use a framework until everything has been migrated (also because I >> > don't want to de-stablise the app too much). ... > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
