Re: Factory vs Abstract Factory

 

 

 

 

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 < kbarrowshartic.com">kbarrowshartic.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. &nbsp;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. &nbsp;I was thinking of using a parameterized
factory to return the correct DAL for that client.&nbsp; I also have several
other objects that are particular to each client and would want to do
the same for those objects.&nbsp; (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. &nbsp;I also want to
create a stand alone Factory DLL that any of our engineers can use in
their apps.

TIA


Keith Barrows
&nbsp; Senior Developer | &nbsp;Engineering Services | (303) 531-4489 |
hartic.com">kbarrowshartic.com &nbsp; &nbsp; ASPInsider <http://aspinsiders.com/>
________________________________

Confidentiality Notice:&nbsp; 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