Small correction to improve clarity: "I didn't talk much about transfer, but transfer is going to both be a factory to create a user object for you *for instance*, ..."
n. On Thu, Feb 5, 2009 at 3:09 AM, Nando M. Breiter <[email protected]>wrote: > Matthew, > > Having been down this road ... > > Barry's solution as a temporary way-station sounds good. I would add to it > that if you can, try to come up with a strategy to manage the creation of > your cfc's and the caching of your singletons, the one's you can persist in > application scope so you don't have to recreate them all the time. So this > implies a factory of some sort. If your .cfm templates create and manage > your cfc's, that will become a headache down the line. > > I can say that you're probably going to go through several rounds of trying > to get it right and then throwing whatever you've done out as you learn more > and more how to organize your code in a more OO fashion, so from this > perspective, Jared has a point. I think one of the biggest reasons I've > settled into a framework stack (ColdSpring, MG and Transfer) is because > architeture is the hardest part of OO by far, and these frameworks by and > large solve the architectural problem for you and hand it to you on a plate. > So yeah, at first glance, learning all these OO frameworks might seem > difficult. But after trying to "get it" on my own, (back in the days when > MachII was first being developed, so there wasn't much of a choice), what I > learned is that OO architecture is tough, and it takes years of experience > to learn. *Every* time I get() or save() a bean with Transfer, there is > still a sign of relief that happens deep in my gut. *Thank you!* > > There is this OO saying that it is difficult to understand a pattern unless > you've experienced the pain ... > > So what I would suggest is a mixture of pain and relief. Use Transfer to > create and persist your business objects (that's the relief part). You'd > create the tranfer factory in your application.cfm or application.cfc as a > singleton. If you don't know how to do that, ask. > > application.transferFactory = *createObject*("component", > "transfer.TransferFactory").init( > > > "/myapp/configs/datasource.xml", > > "/myapp/configs/xml/transfer.xml", > "/myapp/definitions"); > > Then you're going to need to create your transfer.xml file to map your > database to your business objects, mapping the relationships you need as you > go. Then transfer will be available to all your .cfm templates and you'd be > cooking with gas. You can do it bit by bit, so nothing traumatic happens. > Almost everything you do there will be reusable if and when you move to a > framework, and you don't have to change the way your application is > structured out front at all. > > Now for the pain part. Actually it's not too painful, but you're on your > own how you want to do this so there is lots of thinking involved. > > The gateway layer is all yours. Build your own factory to manage your > gateway objects, persist it in application scope so the factory is available > to all your templates, and call the factory from your .cfm templates to get > the gateway objects. Build out your gateways as you think makes sense. (In > our usual way of using the term, a gateway object deals with "more than one > row" so to get a list of users, from the top of my (actually your) .cfm > template, i'd call > > <cfset qUsers = application.appFactory.getUserGateway().findAllUsers() /> > > Note that you can persist your gateway object within your appFactory if you > like, so in effect you'd return the already created object, if it exists. > How would you build that into your factory? It's up to you. > > Soon, it will occur to you that you need some object that shouldn't be > persisted as a singleton. How do you handle that? Should you add another > factory for transient objects? What about an object in session scope? Lots > to think about. All yours. That's the pain part. ;-) > > If you set it up like that, then you'd be able to reuse your gateways as > well if you move to a framework later on. You'd probably throw out the > factory, but not the experience (of that I'm SURE). > > I didn't talk much about transfer, but transfer is going to both be a > factory to create a user object for you, and it will handle all database > interaction for the user object as well. It does a lot more. It has a very > flexible cache mechanism for instance, lot's of stuff that as you learn more > and more about transfer, you'd be able to use in your app. > > So for the gateway part (and anything else that comes along), you'd > architect and write all the code, and for your business objects, transfer is > going to manage it and you're just going to ride on top of the layer of > abstraction transfer provides for you. > > My suggestion ... as you prefer, but that's how I think I'd ease you and > your application into OO if you were working with me. > > Nando > > > > On Wed, Feb 4, 2009 at 1:31 PM, Barry Beattie <[email protected]>wrote: > >> >> @Matthew >> >> by far, Jared's answer is the better one. But coming with that is the >> need to manage the boss's stress levels. >> >> meh, it depends on the culture of the place you work at and how >> critical and complex the app is. If you've identified all the "gold >> code"** and can prove you can change it and not disapear down a rabbit >> hole of fixing and refixing then selling the idea of wholesale changes >> might be easier: a mini project to breathe new life (and longevity) >> into it. >> >> I think we're all assuming that this app is a money-spinner/has a long >> life in front of it/you've sold the boss on the time saved in future >> maintance and enhancements. If the boss is truly sold, then Jared's is >> the better answer. But if not, then you're just going to have to eat >> that elephant one mouthful at a time - if only to save your sanity >> every time you open up the spaghetti tin to fix something... >> >> >> >> >> ** critical code that took a lot of hard work to get right - the >> really precious bits. >> >> >> >> >> On Wed, Feb 4, 2009 at 9:03 PM, Jared Rypka-Hauer >> <[email protected]> wrote: >> > >> > Fair enough. While I agree that the idea of having to rewrite all >> > those URLs is certainly daunting, the refactoring job would take .1 >> > the time because you would have to change so little to gain so much >> > encapsulation and cohesion, even in a procedural codebase, and in >> > doing so you would get to know the application which would, in turn, >> > make refactoring the model to CFCs just that much easier. >> > >> > I did this once. I refactored a small spaghetti-code CMS into a >> > Fusebox application. The best example was the 11 main section pages... >> > they were all identical except for some hard coded text... so I took >> > the 11 templates, chopped the query into one fuse, and the UI into >> > another fuse. Then I created 11 other fuses that created the hardcoded >> > text and included the other 2 fuses. With one more fuse to handle >> > layout so I could wrap the main part of the view in the HTML and body >> > tags and stuff, I was able to go from 11 redundant files to 3 CFM >> > files, 3 circuits for plumbing and 11 carbon-copy fuses that used the >> > XML vocabulary to create 2 variables. Best example of Fusebox as a >> > refactoring tool ever. >> > >> > As for having to handle all those URLs, well, if you were to set up >> > the ColdFusion 404 error page you could do a quick and easy lookup >> > against a struct. I honestly think that if you came up with a naming >> > convention for your circuits so the circuit name could be extrapolated >> > from the file name, you wouldn't have much to worry about. >> > >> > OK, so I've said my piece and probably irritated everyone no end... >> > please don't think I'm trying to cram frameworks down anyone's throat. >> > I just wouldn't want you to miss an opportunity and informed consent >> > is really important... so now that I've spilled my guts I'll leave it >> > alone. I promise. :D >> > >> > J >> > >> > On Feb 4, 2009, at 2:00 AM, Barry Beattie wrote: >> >> >> >> 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. ... >> > >> > >> > On Feb 3, 2009, at 11:35 PM, Matthew 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 >> > >> > > >> > >> >> >> >> > > > -- > > CP 234 > 6934 Bioggio > Switzerland > > +41 (0)91 608 2402 > +41 (0)76 303 4477 > > > -- CP 234 6934 Bioggio Switzerland +41 (0)91 608 2402 +41 (0)76 303 4477 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
