Thanks a lot, Alan. Maybe that's just what I need... baby steps and all. much appreciated.
Marc On Wed, Jul 2, 2008 at 1:23 PM, Alan Livie <[EMAIL PROTECTED]> wrote: > > We're finally moving to Coldspring and the team are happy with working with > our small custom factory. > > It was based on Rob Gonda's one, its easy for the team to learn from the > source code and feels like a good stepping stone to Coldspring getting > developers confident and up to speed. > > http://www.robgonda.com/blog/index.cfm/2007/2/23/Object-Factories-and-Circular-Dependencies > > We've had no trouble with it and its been used on our app for the last 12 > months. > > Alan > ________________________________________ > From: [email protected] [EMAIL PROTECTED] On Behalf Of Marc Esher > [EMAIL PROTECTED] > Sent: 02 July 2008 18:18 > To: [email protected] > Subject: [CFCDEV] Re: Advice on > > @Sean, yup, makes perfect sense! > > @Alan, I think really what Sean's proposing is sort of just a variant > on the abstract factory anyway. Or maybe I'm wrong about it, but when > it gets into "objects that decide what objects to use", to me, that's > a factory. be it one i roll myself or coldspring or lightwire, it's > all just factories at that point (I think... maybe that's reducing it > a bit much). > > I think where I am now is deciding how far to take it. One thing I > have to consider, unfortunately, is maintenance a year from now. Where > I currently work, the culture is currently decidedly "framework? huh? > whoosie? whatda?" So if I were to convert this to using coldspring, > that adds additional learning curve for the poor bastards who have to > maintain it, because i sure as hell don't want to open this thing up > again after I'm finished. if I roll my won, it'd just be in code in a > simple factory object (or set of objects), and they'd at least be able > to follow it right out of the box (I hope.). > > this does sound like a decision best put off until i've had a few beers > though. > > and alan, thanks for the complement! > > marc > > On Wed, Jul 2, 2008 at 1:12 PM, Alan Livie <[EMAIL PROTECTED]> wrote: >> >> This is a good discussion! >> >> I must admit I like Brian's Abstract Factory idea but does it have to be as >> complex as Abstract Factory (you can tell they scare me a bit :-) >> >> Would a simple Factory not do the job. ie the db can store in a table a >> version number and the factory can give the Service the relevant DAO's / >> Gateways it needs to work on the db? >> >> ie you have a standard xxxxxDAO.cfc and a xxxxxDAOv2-1.cfc and the Factory >> determines what to use. >> >> You can do the same with your views if you need slightly different displays >> and have a cfc handle the logic of what view to use. >> >> Even this factory approach has a strict Java / C# OO feel about it. It can >> be even simpler so the factory just gets the version from the db and does a >> <cfset >> variables.xxxService.setxxxDAO(getBean("xxxDAOv#variables.qDbVersion.versionNumber#") >> /> and the setter in the service has a type="any" ... ie no need for >> interfaces or abstract dao class types >> >> Something along those lines anyway! >> >> Lovin' mxUnit by the way Marc :-) >> >> Alan >> ________________________________________ >> From: [email protected] [EMAIL PROTECTED] On Behalf Of Tom Chiverton >> [EMAIL PROTECTED] >> Sent: 02 July 2008 16:48 >> To: [email protected] >> Subject: [CFCDEV] Re: Advice on >> >> On Wednesday 02 Jul 2008, Marc Esher wrote: >>> That's true. It's mainly a matter of time and money. If we have 10 >>> systems, and there's a need to change (like my candy example), it >>> generally is a need that arises from a single system but which will >>> get pushed into all other systems eventually. It's just that it can >>> take a bit of time to get the other systems in compliance. >> >> So would simply versioning the DB schema against a version of the application >> work then ? >> Then as the other DBs get the same update done, you roll out the mathcing >> application rev. ? >> >> -- >> Tom Chiverton >> >> **************************************************** >> >> This email is sent for and on behalf of Halliwells LLP. >> >> Halliwells LLP is a limited liability partnership registered in England and >> Wales under registered number OC307980 whose registered office address is at >> Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A >> list of members is available for inspection at the registered office. Any >> reference to a partner in relation to Halliwells LLP means a member of >> Halliwells LLP. Regulated by The Solicitors Regulation Authority. >> >> CONFIDENTIALITY >> >> This email is intended only for the use of the addressee named above and may >> be confidential or legally privileged. If you are not the addressee you >> must not read it and must not use any information contained in nor copy it >> nor inform any person other than Halliwells LLP or the addressee of its >> existence or contents. If you have received this email in error please >> delete it and notify Halliwells LLP IT Department on 0870 365 2500. >> >> For more information about Halliwells LLP visit www.halliwells.com. >> >> >> >> > >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
