0

我很好奇在以下实现中使用的最佳设计模式是什么：我正在创建一个小应用程序来从网站下载图像并将其设置为我的背景。

我想与网站交互以下载 XMLBackground.xml文件并下载Background.bmp托管在此远程服务器上的另一个文件 ( )。该文件是位图，XML 是有关位图的元数据。下载文件后，我想将其设置为我的背景。我想将文件下载代码与后台设置代码分开，但我不确定我会使用哪种设计模式。

这似乎是一个典型的表示/数据/业务应用程序，其中表单是表示层，后台设置器/XML 解析器是业务层，下载器是数据层。但是我不确定我将使用哪种设计模式来进行实际的数据访问，因为它来自网站而不是数据库（因此 DAO 可能不适合这个）。我还在Wikipedia上购买了设计模式，但似乎没有什么是正确的。这是我可以使用 MVC 的东西吗？

数据层

public class DataLayer {
    public void DownloadFile() { 
        // download the file from http
    }
    public void GetXmlMetaData() { }
}

业务层

public class BusinessLayer {
    private static BusinessLayer m_instance = new BusinessLayer();  
    public static Instance BusinessLayer { get { return m_instance; }
    private BusinessLayer() { }

    public void SetNewWallpaper() { 
        // download the file from data layer
        // set it as the background
    }
    public String GetWallpaperInfo() { return String.Empty; }
}

表示层

public class PresentationLayer {
    public void HandleButtonClick(Object sender, EventArgs e) {
        BusinessLayer.Instance.SetNewWallpaper();
    }
}

如何将数据访问部分与后台设置逻辑分开？

4

2 回答 2

1

你正处于模式化阶段。很多人都会经历这个阶段。当您了解模式、学习其中的一些并且已经想在可以应用的任何地方应用它时，它就会出现。

尝试使用某种模式编写代码只是为了实现其中的一些，这不是最佳实践。不要为代码本身编写代码。尝试以最简单干净的方式解决业务任务，这是最好的方法。模式应该可以帮助您做到这一点。

您已经将代码的不同层分开了，这很好。您的架构非常简单，并且您接近 MVC。我认为你应该在这一点上停下来不要增加复杂性。

关于 DAO，它意味着数据访问对象。没有关于数据库的任何消息。DAO 可以为您提供对任何数据源的访问：数据库、缓存、nosql 存储、文件、数据仓库（您的情况）等。这很棒，因为您可以为您的应用程序动态更改数据源，如果它们实现统一接口，只需在它们之间切换.

于 2013-05-01T08:49:53.427 回答
1

我很好奇在以下实现中使用的最佳设计模式是什么

基于什么标准？下载文件并用它做 X，与构建飞机维护和零件跟踪系统不同。复杂性、软件生命周期、团队规模、预算、时间框架，都会影响“最佳方法”

一旦您知道为什么要应用哪种软件设计原则，那么它就更容易到位。

我想将文件下载代码与后台设置代码分开，但我不确定我会使用哪种设计模式。

为什么？是的，这是一个很好的做法，但有理由分开。减少错误，增加代码重用，促进更好的单元测试，消除依赖，使维护更容易，解耦......你可以：

a) 将所有代码放在一种方法中是一种极端。
b) 在一个类中使用许多方法。升级
c) 下一步将项目中的类分开。基本 OO
d) 在解决方案中创建单独的项目。更多的设计模式
e) 构建独立的沟通解决方案。另一个极端。

鉴于您对应用设计原则的偏好，您很可能会查看 C) 或 D)。

您选择的选项本身可以有变体，例如依赖注入/控制反转模式。但我会建议你不要尝试在前面这样做。听起来你的应用程序有点矫枉过正。

这似乎是一个典型的演示/数据/业务应用程序

是的，但 90% 以上的项目将以某种方式进行。没有你不提供的数据没什么意义。没有数据的演示文稿没有多大意义。

鉴于您在发布时接近 2K 的 Rep，您显然可以编码。所以我要建议：用 3 个项目构建一个解决方案。

  1. 数据访问
  2. 业务层
  3. 演示文稿。
  4. 具有简单类 (POCO) 和基本对象逻辑的核心模型项目
  5. 依赖注入/控制反转

仅在非常热衷的情况下才考虑 4 或 5，并且最好保留 DI/IOC，直到您对 1/2/3/4 类型的解决方案感到满意为止。

避免从前端项目引用/调用数据访问项目。

核心模型不应引用其他项目。

这是我可以使用 MVC 的东西吗？

是的，你可以。前端项目有一个控制器（或 2 个）控制器“调用”前端项目中的视图。视图仅显示用户并从用户那里获取数据。控制器调用另一个层。例如，控制器调用业务流程层可能会多次调用数据层以获取所有必需的信息并对其进行更新。

如果您想了解有关 MVC 的更多信息，请查看此处http://www.asp.net/mvc/tutorials 。这些教程并不总是干净地“分开”，因为它们专注于 MVC 方面。事实上，您将在控制器中间看到数据访问。演示者在实际项目中永远不会这样做。

使用基本 MVC 模式的单个项目对于小型一次性应用程序来说已经足够了。多个项目使“演示”复杂化。但想象一下，您需要一个 Windows WPF 版本的应用程序。并在 MVC 项目中查看数据访问代码。那里没有太多重复使用。这更好地解释了为什么分离是好的原因类型。

祝你好运...

于 2013-05-01T13:20:16.443 回答