Last post Mar 28, 2012 12:28 AM by atconway
Mar 27, 2012 12:05 PM|JTCOO|LINK
Thanks in advance. I realize that this is an ancient problem, I'd just like an explanation and maybe a workaround that doesn't involve me creating my own XML file to read (which I've done in the past).
I'm trying to maintain separation of the data access layer and the rest of my ASP.NET application. I don't want my web application to have to know where the data is stored or how to get to it other than being able to call methods in my data access layer
library, especially since it needs to handle calls to two different databases with the same class (intranet and DMZ databases). My app.config for the DLL is useless once it's published to the web server. I would love it if there was a way to alter the settings
in the DLL without recompiling and without forcing the ASP.NET application to pass the connection string to the class objects each time they are created. The data access layer is perfectly capable of determining what database to connect to without involving
the web application.
Update: Another reason I want the DLL to have control over the connection string setting and selection is because the DLL will be used by multiple applications, so a change requires changing any application that references it instead of just changing it
in one place.
Is there a best practice on this or do I just have to either put the connection strings into the web.config file or create my own configuration system for the DLL?
Mar 28, 2012 12:28 AM|atconway|LINK
Class libraries do not support their own configuration. A long time ago I tried to have the .config with a .dll added to the /bin as content, and manually open it up for reading but it was a really bad hack. It technically worked but was far from best practice
of any type. It was the result really of my lack of understanding a better way to solve the problem.
The 1st thing that came to my mind when reading your question is how much your DAL could benefit from using something like the repository pattern. This pattern would allow the creation of a single Interface defined say by your domain for persistance guidlines,
but actually implemented 1:n times in the DAL (never implemented in the domain layer). Each implementation would be for a different database in your case and via congifuartion, you could switch databases easily without recompliling.
As for the connection string settings? Typically the DAL is part of a larger architecture and is not just floating around on its own. I like to use an Infrastructure layer to wrap configuration settings from the host application (does not matter the type:
ASP.NET, WinForms, Silverlight, WPF, whatever) and allow the DAL access to this layer. It is a vertical layer that spans all layers and all layers can use it. It is often a glorified Utilities component.
The book Professional ASP.NET Design Patterns has a lot of information on all of this if you are interested.