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