如何将远程数据访问（通过 http）逻辑与业务逻辑分开？

Posted 2023-02-24

【中文标题】如何将远程数据访问（通过 http）逻辑与业务逻辑分开？

【英文标题】：How do I separate remote data access (via http) logic from the business logic?

【发布时间】：2013-04-25 02:01:57

【问题描述】：

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

我想与网站交互以下载 XML Background.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();
    

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

【参考方案1】：

我很好奇在 后续实现

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

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

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

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

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

鉴于您对应用设计原则的偏好，您最有可能关注 C) 或 D)。

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

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

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

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

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

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

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

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

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

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

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

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

祝你好运……

【参考方案2】：

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

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

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

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