伙计们，
我有一个 ASP.NET 项目，它按命名空间划分为 n 层，但我需要分成三个项目：数据层、中间层和前端。
我这样做是因为……
A) 这似乎是正确的做法，并且
B) 我在为 ASP.NET 托管程序集运行单元测试时遇到各种问题。
无论如何，我的问题是，您将配置信息保存在哪里？
例如，现在，我的中间层类（使用 Linq to SQL）在实例化新数据上下文时会自动从 web.config 中提取其连接字符串信息。
如果我的数据层在另一个项目中，它可以/应该使用 web.config 获取配置信息吗？
如果是这样，单元测试（通常在单独的程序集中）将如何提供 soch 配置信息？
感谢您的宝贵时间！
【问题讨论】：
标签： asp.net web-config data-access-layer n-tier-architecture 3-tier
出于测试目的，请勿使用默认 ctor 实例化 DataContext。将连接字符串信息传递给构造函数。
我更喜欢使用 IoC 框架将连接注入数据上下文，然后将上下文注入其他类。
【讨论】：
我们将它们保存在一个恰好是 XML 的全局“设置”文件中。此文件包含所有 GLOBAL 设置，其中之一是指向相应 服务器 的连接字符串以及用户名和密码。然后，当我的应用程序使用它时，它们会将所需的特定目录（数据库）放入连接字符串中。
我们为每个操作环境（prod、dev、staging 等）都有一个文件版本。然后，通过两个设置——文件路径（带有代表环境的标记）和环境——我可以选择正确的设置文件。
这还具有 30 秒故障转移的好处。只需在设置文件中更改服务器名称并重新启动应用程序（Web），您就可以进行故障转移（当然，如果需要，您必须恢复数据）。
然后当应用程序启动时，我们将正确的连接字符串写入 web.config 文件（如果不同的话）。有了这个，我们可以通过更改一个 appSettings 值将网站从 DEV 更改为 PROD。
【讨论】：
只要不是太多，放在web.config里面就很方便了。当然，您的 DAL 绝对不知道它来自那里。
一个不错的选择是让您的数据层在被要求执行某项操作时获得其配置信息，并在网络调用进入时被要求执行某项操作。继续将信息放入您的网络配置。在我当前的项目中，我的数据层中有一个连接字符串的静态字典，我在从 global.asax 调用的例程中填写它：
CAPPData.ConnectionStrings(DatabaseName.Foo) =
ConfigurationManager.ConnectionStrings("FooConnStr").ConnectionString()
CAPPData.ConnectionStrings(DatabaseName.Bar) =
ConfigurationManager.ConnectionStrings("BarConnStr").ConnectionString()
etc.
像这样“注入”它可以有利于自动化测试，具体取决于您如何/是否测试您的 DAL。对我来说，这只是因为我不想制作单独的配置文件。
【讨论】：