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