Thanks everyone: @Jared: thanks for re-affirming your point - it makes sense but I still feel that I'll see more improvements in maintenance time by concentrating on the MODEL layer first (perhaps I'll see you were right at the end of it all). @Barry: it's a pretty complex app... well the business logic is the complex bit, there are so many rules (with tiny little differences) that you go crazy (but I love a challenge - I hate easy, predictable coding). This is probably why I'm focusing on improving the MODEL because there are often changes in this layer. @Nando: thanks for such a long response. You've given me a few ideas and perhaps I will look at plugging in Transfer so that I don't get arthritus writing all the BEAN/DAO cfc's :)
Cheers Matthew On Feb 5, 1:16 pm, "Nando M. Breiter" <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
