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