我正在组织一个解决方案，我需要一些关于如何正确安排项目组件的提示。
现在我已经在一个项目上实现了所有功能，但我觉得在自己的项目中隔离一些组件是有意义的。我拥有的主要模块按项目中的文件夹分类，是Logic模块，Database Access模块和Model模块。我觉得这些模块应该在他们自己的项目中定义（可能是一个DLL）。
现在，我的问题来自这样一个事实，即在应用程序启动期间，逻辑实例化一个配置类，该类从 app.config 文件中读取配置，并且这些模块已知。将配置隔离到自己的项目中是否有意义，以防止其他模块依赖于逻辑模块？如果是这样，配置类是否应该从接口实现，以便每个模块只能访问它的相关配置？
答案 0 :(得分：3)
“我拥有的主要模块按项目中的文件夹分类，并且 是逻辑模块，数据库访问模块和模型模块...... 逻辑实例化一个读取的配置类 来自app.config文件的配置，并且这些配置是已知的 模块“。
这给我描绘的图片是你有一个或多个类，它们将配置类作为构造函数参数，或者是其他类使用的配置类的全局/单例实例。 / p>
但是配置类可以读取配置等。据推测，其他类不需要能够读取配置的东西。他们只需要一些值*（现在可以从配置中读取）。那些其他课程不需要出去向任何人询问这些价值观**;他们应该只需要将这些值作为其构造函数中的参数。
这样，其他类不需要了解配置类。有人只是提供他们需要的数据。但谁呢？
答案是入口点***。包含入口点（控制台应用程序，Web应用程序和测试项目）的解决方案中的每个项目都有责任与环境进行交互;它知道它希望其余代码运行的上下文。因此，入口点需要通过任何必要的方式获取配置信息（例如，您的配置类或自动生成的MyEntryPoint.Properties.Settings），然后将其提供给构造函数他们需要的其他课程。
*如果每个类都需要大量的配置信息（如下面的评论所示），请考虑将这些类分解为更简单的类（因为需要大量配置可能指向不明确的责任）或将代表连贯概念的DTO的必要信息。然后可以将这些DTO放置在他们自己的项目中，供消费者和配置信息的生产者参考。
**这假设从配置类获得的值对于将使用它们构造的对象的生命周期是恒定的。如果没有，那么您应该使用一个接口（或Func）来获取您需要的信息，而不是将这些值作为构造函数参数。这些接口可以在任何人都可以参考的其他空项目中定义。这听起来像你正在使用的
“配置类应该从接口实现，以便每个模块只能访问它的相关配置吗？”
当你说
时“将配置隔离到自己的项目中是否有意义，以防止其他模块依赖于逻辑模块？”
答案是肯定的，不是。逻辑模块做的东西;做事意味着需要测试;测试想要以适合测试的任何方式配置他们正在测试的任何东西。所以Logic不应该对配置负责;它本身应该从任何进行配置的人那里获取信息。相反，配置是入口点的工作。
***我在这里稍微松散地使用“切入点”。我不是特别谈论.entrypoint IL指令，而只是代码中的第一个可以通过控制之外的东西控制的地方。这包括主要的C＃控制台应用程序，Web应用程序中的HttpApplication.Application_Start，被您选择的测试运行程序认可为测试的方法等。