|
List Info
Thread: Re: Factory vs Abstract Factory
|
|
| Re: Factory vs Abstract Factory |

|
2007-04-20 10:41:04 |
|
| Sweet! Thanks.
| Keith
Barrows |
 |
Senior Developer | Engineering
Services | (303)
531-4489 | kbarrows hartic.com |
ASPInsider
|
Confidentiality Notice: This
email message, including all the attachments, is for the sole use of the
intended recipient(s) and contains confidential information. Unauthorized
use or disclosure is prohibited. If you are not the intended recipient,
you may not use, disclose, copy or disseminate this information. If you
are not the intended recipient, please contact the sender immediately by
reply email and destroy all copies of the original message, including
attachments.
|
Then the dependency injection pattern would probably be a good
fit. Look at the object builder not-a-block-yet block in EntLib and maybe
read up on the pattern. It's good for runtime substitution (injection) of
providers/factories.
On 4/19/07, Barrows,
Keith < kbarrows hartic.com">kbarrows hartic.com>
wrote:
Disclaimer
noted. 
I'm
approaching this as a single UI that we take on a thumb drive (or
whatever). Once at the client site we select some specific info and the
factories give back the specific implementations for that client. I've
always viewed providers as a more static thing. Add the info to a config
file and then the app uses that configuration only. The end users of
this app are us, the Engineering Services group, not the client staff.
Definitely
using the EntLib for the DAAB pieces.
|
|
| Keith
Barrows |
 |
Senior Developer | Engineering
Services | (303)
531-4489 | hartic.com" target=_blank>kbarrows hartic.com
|
ASPInsider
|
|
|
Confidentiality Notice: This
email message, including all the attachments, is for the sole use of the
intended recipient(s) and contains confidential information.
Unauthorized use or disclosure is prohibited. If you are not the
intended recipient, you may not use, disclose, copy or disseminate this
information. If you are not the intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message, including attachments.
|
It sounds like you need a provider model (strategy pattern) or maybe the
dependency injection pattern. Concretely, you could look into maybe the
EntLib db block and/or an ORM (there is an ORM that sits on top of the
EntLib). Depending on the extremity of differences between your data
sources, just using the DB block may suffice; however, from the sounds of it,
I'd lean towards an implementation like the provider model with a strong
domain model (or at a minimum known DTOs). You can also toss in a
property bag on your objects for extra informational data that doesn't need to
be known by the app ( i.e., doesn't affect behavior) but still needs to be
available for consumption by end users.
Standard 10-minute architectural advice disclaimer applies.
--Ambrose
On 4/19/07, Barrows,
Keith <hartic.com" target=_blank>kbarrows hartic.com >
wrote:
I'm
trying to decide which is the better way to go.
I support an
application that can be deployed on 6 different database
platforms. Every time a deployment is done to a client site
there are minor things that can change within a database (add extra
columns, don't use certain columns, etc). My tool needs to do
the same action no matter what client I am at. I was thinking
of using a parameterized factory to return the correct DAL for that
client. I also have several other objects that are particular
to each client and would want to do the same for those
objects. (Image handler, Shell command
handler, etc).
I'm leaning to using a Factory as opposed to an
Abstract Factory and was wondering if anyone had any thoughts or
suggestions. I also want to create a stand alone Factory DLL
that any of our engineers can use in their
apps.
TIA
Keith Barrows Senior Developer
| Engineering Services | (303) 531-4489 | hartic.com"
target=_blank>kbarrows hartic.com ASPInsider
<http://aspinsiders.com/> ________________________________
Confidentiality
Notice: This email message, including all the attachments, is
for the sole use of the intended recipient(s) and contains confidential
information. Unauthorized use or disclosure is prohibited. If you are not
the intended recipient, you may not use, disclose, copy or disseminate
this information. If you are not the intended recipient, please contact
the sender immediately by reply email and destroy all copies of the
original message, including attachments.
________________________________
________________________________
________________________________
________________________________
________________________________
________________________________
Need SQL Advice? http://sqladvice.com Need
RegEx Advice? http://regexadvice.com Need XML Advice? http://xmladvice.com
Need
SQL Advice? http://sqladvice.com Need RegEx
Advice? http://regexadvice.com Need
XML Advice? http://xmladvice.com Need SQL
Advice? http://sqladvice.com Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com Need SQL
Advice? http://sqladvice.com Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com
Need SQL Advice? http://sqladvice.com
Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com
Need SQL Advice? http://sqladvice.com
Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com
|
Approximate file size 4672 bytes |
[1]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|