0

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

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

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

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

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

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

DAL：每种不同类型的数据库平台都有一个类，所有这些类都必须实现我设计的“DatabasePlatform”接口。这背后的想法是允许我在以后添加额外的平台，几乎不需要修改代码（我正在尝试降低“开放封闭”的原则！）

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

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

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

4

1 回答 1

0

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

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

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 可以是静态的或单例的。

如果你使用依赖注入，你可以注册 IProvider 有点像 'IOC.Register.To(RuntimeConfigurationService.DBProviderFactory.Create())'

于 2012-06-01T15:24:53.070 回答