Question

我想首先说我对软件开发相对较新（过去一年我一直在自学）。

我最近一直试图了解软件应用程序中的不同层，即UI，业务逻辑层和数据访问层。为了将我学到的知识付诸实践，我正在开发一个应用程序，它允许您备份数据库，然后在以后恢复备份。

我的问题是，我该如何设计我的'系统'和'用户'选项。例如，我想允许用户选择他们选择的数据库平台（即SQL或Oracle）。我打算将信息存储在XLM文件中。我只是不知道如何以编程方式访问此信息（我执行了解如何读取和写入XML文件。

我目前的架构看起来像这样:(请注意，这可能是一个糟糕的设计，我很高兴并且愿意接受建设性的批评）。

UI：主要MDI。用户选项表单数据库管理器表单

BLL： Database Manager类用于驱动数据库管理器表单。

DAL：每个不同类型的数据库平台有1个类，所有这些类必须实现我设计的'DatabasePlatform'接口。这背后的想法是允许我在以后添加其他平台，几乎不修改代码（我试图让'Open Closed'原则失效！）

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

最后，我的系统选项是否应放入静态类中，以便我可以从任何其他类/表单/实体调用我的系统选项而无需创建实例？

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

Answer 1

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

这是实体组织的一种可能方式。

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 Create();。

然后，当某些BLL或其他类需要提供者时，它会调用RuntimeConfigurationService.DBProviderFactory.Create()，获取IProvider接口并使用它。

RuntimeConfigurationService可以是static或singleton。

如果您使用依赖注入，您可以注册IProvider，就像'IOC.Register.To（RuntimeConfigurationService.DBProviderFactory.Create（））'

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

1 个答案: