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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
