Oop 系统选项属于哪一层？它们是如何实现的？如何以编程方式访问它们？

首先，我想说我对软件开发比较陌生，我在过去的一年里一直在自学

我最近一直在尝试了解软件应用程序中的不同层，即UI、业务逻辑层和数据访问层。为了将我学到的知识应用到实践中，我正在开发一个应用程序，它允许您对数据库进行备份，然后在以后的某个日期将它们还原为备份

我的问题是，我应该如何设计我的“系统”和“用户”选项。例如，我希望允许用户选择自己选择的数据库平台，即SQL或Oracle。我计划将信息存储在XLM文件中。我只是不知道应该如何以编程方式访问这些信息，我知道如何读取和写入XML文件

我目前的架构是这样的：请注意，这可能是一个可怕的设计，我很乐意接受建设性的批评

用户界面： 主MDI。 用户选项表单 数据库管理器窗体

BLL： 数据库管理器类来驱动数据库管理器窗体

达尔： 对于每种不同类型的数据库平台，所有这些类都必须实现我设计的“DatabasePlatform”接口。这背后的想法是允许我在以后添加额外的平台，而不需要对代码进行任何修改，我正试图让“打开-关闭”原则停止

我有点不确定，并且非常困惑，我的系统选项在哪里以及如何适应所有这些，以及最终在哪里放置它们？在什么时候检查系统选项？它是在UI中还是在BLL中？ 我觉得不应该在DAL中检查，因为我需要知道选择哪个DAL。。。。也许我设计的完全错误，应该在DAL中进行检查？我很困惑

最后，我的系统选项是否应该放在一个静态类中，这样我就可以从任何其他类/表单/实体调用我的系统选项，而无需创建实例

---

我非常感谢并欢迎任何反馈/批评。对于任何语法问题，我深表歉意，英语不是我的第一语言。

如果我理解正确-这是基础架构层的一部分，问题是如何在解决特定业务问题之前正确设置运行时

这里有一种可能的实体组织方式

UI表单从配置源xml文件加载它的模型，并显示一个下拉控件。根据用户的反应，它将消息发送到RuntimeConfigurationService，类似于RuntimeConfigurationService.SettingsChanged

我假设您存储数据的方式与BLL没有直接关系。这就是我将RuntimeConfigurationService指定为应用程序基础架构层的一部分的方式

RuntimeConfigurationService可以执行以下操作：

SettingsChanged(name) {
    DBProviderName = name;
    DBProviderFactory = CreateFactory(name);

    CreateFactory(name) {
        switch(name)
         case "sql": return new SQLProviderFactory();
         case "oracle": return new OracleProviderFactory();
    }
}

两个工厂都实现了IProvider创建的方法；以他们自己的方式

然后，当某些BLL或其他类需要提供程序时，它调用RuntimeConfigurationService.DBProviderFactory.Create，获取IPProvider接口并使用它

RuntimeConfigurationService可以是静态的，也可以是单例的

---

如果您使用依赖项注入，您可以注册类似于“IOC.register.ToRuntimeConfigurationService.DBProviderFactory.Create”的IProvider。好吧，我理解您的顾虑。但是，您提出的问题太多，无法在评论中得到回答—一个完整的应用程序设计，从用户界面到业务逻辑，再到数据访问层，等等。其次，要回答这些问题，您需要知道比您在这里所说的多得多的内容。我建议您阅读分层体系结构。这是大多数此类应用程序的解决方案。我认为您最终需要的是分层架构的一些变化。首先，我想为延迟响应您的答案道歉。你的回答包括3个非常新的，对我来说非常重要的关键词。工厂，静态和单件。这让我开始了为期3周的学习这3种设计模式的旅程。我并没有真正理解设计模式是什么，或者它们是如何在真实场景中实现的。您提供的代码片段对此非常有帮助。我非常感谢你花时间回复我。这正是我所需要的，让我走上扩展系统设计知识的道路。有空我请你喝一杯：