Implementing a pluggable DAL for many business libraries

Implementing a pluggable DAL for many business libraries

Old forum URL: forums.lhotka.net/forums/t/10103.aspx


OscarLauroba posted on Thursday, February 24, 2011

Hello,

The rev o.4 of csla 4 DataAccess book talks about implementing a pluggable DAL. I'm wondering how to implement this for many business libraries. Do I need one DAL Interface assembly for each business library or Could I have only one DAL interface library for all the business libraries of the application?

Solution a)

BusinessLibrary1 --> Dal_Interface1 --> ConcreteDAL1

BusinessLibrary2--> Dal_Interface2 --> ConcreteDAL2

BusinessLibraryN--> Dal_InterfaceN --> ConcreteDalN

Or solution b)

Library1, Library2,..., LibraryN --> Dal_Interface --> ConcreteDAL1, ConcreteDal2, ..., ConcreteDalN

Or Your solution Smile

Dal_Interface library uses an app.config to decide the Concrete DAL assembly to load. Would I need an app.config for each dal_interface in solution a)? This would cause a lot of work switching from production to mock assemblies if I wanted to test the whole application.

Sincerely,

Oscar.

RockfordLhotka replied on Thursday, February 24, 2011

As I mention in the book, there are a LOT of solutions to this problem, including the use of IoC frameworks/containers, provider models, MEF, etc.

In the book I show one example, that works for many scenarios. But (for example) Magenic has customers who use Unity and some that use MEF and some who just hard-code the connections.

Not that I advocate the hard-coded solution - but not all orgs are culturally ready to create mock DAL providers or really implement testing - so sometimes you just gotta roll with the ambient culture :)

I don't personally feel qualified to say that any given design pattern or approach is "the gold standard". Given the high passions that surround this sort of topic, any statement like that would surely start one or more flame wars - and I just don't have time for that right now :)

Copyright (c) Marimer LLC