在n层架构中应在哪里输入应用程序设置，测试和合同/界面？

如何解决在n层架构中应在哪里输入应用程序设置，测试和合同/界面？

| 我正在使用Visual Studio 2010创建n层应用程序。 我有一个仅具有应用程序配置的项目，一个仅具有测试的项目，以及仅具有合同（接口）的项目。 在逻辑模型中，应在哪里输入应用程序配置值，测试和合同？ 这是好习惯吗？     

解决方法

您要为要测试的每个项目单独的测试项目。假设它们是真正的单元测试，则例如

VENUS.Repository.Tests

将仅直接引用

VENUS.Repository

。在实践中，除非您模拟所有内容，否则可能不会完全实现，但是，分离项目仍可以使您更加清楚目的。 我认为针对“合同”（我假设的接口）的单独项目是错误的。接口是一层用来引用其他层的公共入口点。因此，它们属于各自的层。也就是说，

IFooRepository

属于

VENUS.Repository

，而不是

VENUS.Contracts

。 （但是，请参阅注释中的讨论。）如果将它们全部放在一个程序集中，您将通过说“要与任何层连接的任何人，只要引用

VENUS.Contracts

，就可以疯狂运行”来破坏n层分隔。 ” 最后，这是更多情况，但是我的直觉是在您的合成根目录（通常是UI层）中有一个配置文件，并在组成它们时将配置依赖项注入到组件中。所以例如连接字符串不在ѭ1中引用的ѭ6中（以及其他所有人），而在

VENUS.UI.Web

的ѭ9中引用。然后，当“ 8”组成其存储库依赖关系时，它将把该配置传递给存储库构造函数。例如：

string fooConnectionString = ConfigurationManager.ConnectionStrings[\"Foo\"].ConnectionString;
IFooRepository fooRepo = new SqlFooRepository(fooConnectionString);
// Now,as you compose the rest of your dependencies,// inject fooRepo into anything that requires an IFooRepository.

（这当然是“穷人的依赖项注入”的示例；如果计划使用适当的依赖项注入框架，将会有更好的组合方法。） 这样，您的存储库层就没有概念上对“配置”概念的依赖，而是仅以自然的面向对象编程方式（构造函数参数）表达其需求。