c# - 组织解决方案，需要技巧

Question

我正在组织一个解决方案，我需要一些关于如何正确安排项目组件的提示。

现在我已经在一个项目中实现了所有内容，但我觉得将一些组件隔离在他们自己的项目中是有意义的。我拥有的主要模块按项目文件夹分类，分别是逻辑模块、数据库访问模块和模型模块。对我来说，这些模块应该在它们自己的项目中定义(可能作为 DLL)是有意义的。

现在，我的问题来自于这样一个事实，即在应用程序启动期间，逻辑实例化了一个配置类，该配置类从 app.config 文件中读取配置，并为这些模块所知。将配置隔离到它自己的项目中是否有意义，以防止其他模块依赖于逻辑模块？如果是这样，配置类是否应该从接口(interface)实现，以便每个模块只能访问它的相关配置？

Answer 1

"The main modules I have are categorzed by folders on the project, and are the Logic module, Database Access module and the Model module... the logic instantiates a configuration class which reads configurations from the app.config file and is known by these modules."

这给我的印象是你有一个或多个类将配置类作为构造函数参数，或者有一个配置类的全局/单例实例供其他类使用。

但是配置类可以读取配置等。推测其他类不需要可以读取配置的东西。他们只需要一些值*(现在可以从配置中读取)。那些其他类不需要出去向任何人询问这些值**；他们应该只需要这些值作为构造函数中的参数。

这样，其他类就不需要了解配置类了。有人只是将他们需要的数据交给他们。但是谁呢？

答案是入口点***。解决方案中包含入口点的每个项目(控制台应用程序、Web 应用程序和测试项目)都有责任与环境进行交互；它知道它希望其余代码在其中运行的上下文。因此入口点需要通过任何必要的方式(例如您的配置类或自动生成的 MyEntryPoint.Properties.Settings)获取配置信息，然后将其提供给构造函数他们需要的其他类(class)。

*如果每个类都需要大量的配置信息(正如您在下面的评论所暗示的那样)，请考虑将这些类分解为更简单的类(因为需要大量配置可能会导致职责不明确)或将必要的信息到代表连贯概念的 DTO。然后可以将这些 DTO 放在它们自己的项目中，供配置信息的消费者和生产者引用。

**这假定从配置类获得的值在将使用它们构造的对象的生命周期内是恒定的。如果不是，则不应将这些值作为构造函数参数，而应采用一个接口(interface)(或 Func)，您可以在需要时调用该接口(interface)以获取所需信息。这些接口(interface)可以在任何人都可以引用的其他空项目中定义。这听起来像你想要的

"should the configuration class implement from interfaces so that each module only has access to it's relevant configurations?"

当你说

"Does it make sense to isolate the configuration into it's own project, to prevent the other modules from depending on the logic module?"

答案是肯定的，也不是。 Logic 模块做一些事情；做事意味着需要测试；测试希望以适合测试的任何方式配置他们正在测试的任何内容。所以 Logic 不应该负责配置；它本身应该从进行配置的人那里获取信息。相反，配置是入口点的工作。

***我在这里使用的“入口点”有点松散。我不是在专门讨论 .entrypoint IL 指令，而只是在您的代码中可以由您无法控制的东西控制的第一个地方。这包括 C# 控制台应用程序中的 Main、Web 应用程序中的 HttpApplication.Application_Start、被您选择的测试运行器识别为测试的方法等。