API /框架设计：设置模式/环境（例如开发模式等）

Question

我想知道为asp.net编写的可重用Web框架的最佳设置方式是什么，适用于手动配置或依赖注入框架。

---

一些背景和解释：我们有一个内部设计的框架，有几种模式：

• 应用模式：dev，test，prod。在配置文件中设置。
• “kiosk”模式：开，关。特定于应用程序，在代码中被覆盖。
• 运行时调试模式：如果是dev应用程序模式，则设置了某个URL参数。
• 特定的调试标志：显示边框，显示性能信息等，由应用程序设置。
• 未来模式......

因此，我们有一些不同的模式可以在配置文件中设置，或者在运行时或启动时由应用程序设置，具体取决于其主要用途。

问题是这些模式是通过框架中的单个“god”类来控制的，该类读取配置文件，url参数，以及具有可以覆盖的虚拟属性以指定“kiosk”模式。

所以这个神类有很多对服务的引用，我可以在构造函数中提取并定义依赖注入。然而，对不同模式的检查遍布整个代码库（如果是dev模式......或者如果是kiosk模式）。就像通过静态方法访问日志库有什么意义一样，我想知道应用程序在asp.net的ApplicationStart事件中设置一些静态方法是否更有意义。

此代码重新洗牌的目的之一是帮助进行单元测试。在模式方面，只需要测试信息亭和非信息亭模式，因为调试模式仅适用于开发人员。

选项：

1. 用于设置模式的单例类/静态方法，在应用程序启动时调用
2. 拥有dev / kiosk特定对象并将其作为依赖项传递，在启动时配置。例如，不仅仅是MailService，还会有DevMailService和KioskMailService。这将意味着许多额外的工作开始。
3. 需要有关dev / kiosk模式或调试选项的知识的类具有启用/禁用的属性。用户可以检查他/她是否正确设置了它们。 （调试模式的合理默认值）
4. 或者在类的构造函数中将模式设置为布尔参数。 （可能对必须正确设置的自助服务终端模式更有用）
5. 一个特殊的“模式服务类”，它通过构造函数传递给需要了解该模式的所有类。
6. 一种特殊的调试模式服务类，必要时可以通过属性设置，默认设置为null对象。
7. 选择的组合。

我倾向于调试设置和标志（3）的属性，用于设置kiosk模式（4）的构造函数参数，但是使用特定的Kiosk和非Kiosk类编写了更新的代码（2）。不太确定如何通过url参数处理调试模式集，但可能通过具有null对象默认值的属性使用调试服务集。 （6）

Answer 1

我认为要记住的最好的事情是务实。代码的额外工作重新洗牌是否超过了好处？对我而言，这听起来像是一个重大的架构变化，而且目前的模型似乎已经相当不错了。

对于我自己的一个项目，我也决定不去进行体系结构更改，因为我们会失去对系统的信任。有时最好知道哪些不能正常工作，而不是通过猜测如何做到这一点而产生很多混淆。