如何将远程数据访问(通过http)逻辑与业务逻辑分离

本文关键字：业务 分离 http 通过 数据 访问 程数据 | 更新日期: 2023-09-27 18:11:31

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

我想与一个网站的接口下载一个XML Background.xml文件，也下载另一个文件(Background.bmp)这是托管在这个远程服务器上。文件是位图，XML是关于位图的元数据。下载文件后，我想把它设置为我的背景。我想将文件下载代码与背景设置代码分开，但我不确定我会使用哪种设计模式。

这看起来像是一个典型的表示/数据/业务应用程序，表单是表示层，后台设置器/XML解析器是业务层，下载器是数据层。但是我不确定我将使用哪种设计模式来进行实际的数据访问，因为它将来自网站而不是数据库(因此DAO可能不适合此)。我还在维基百科上搜索了设计模式，但似乎没有什么是正确的。这是我可以用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();
    }
}

如何将数据访问部分从后台设置逻辑中分离出来?

如何将远程数据访问(通过http)逻辑与业务逻辑分离

我很好奇什么是最好的设计模式后实施

基于什么标准?下载一个文件然后用它做X，与建立一个飞机维护和零件跟踪系统是不一样的。复杂性、软件生命周期、团队规模、预算、时间框架，所有这些都会影响"最佳方法"

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

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

为什么?是的，这是很好的做法，但有理由分开。减少bug，增加代码重用，促进更好的单元测试，消除依赖，使维护更容易，解耦……您可以:

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

考虑到你对应用设计原则的偏好，你很可能会选择C)或D)。

你选择的选项可以有自己的变体，比如依赖注入/控制反转模式。但我建议你不要一开始就这么做。对你的应用来说，听起来有点小题大做。

这看起来像是一个典型的表示/数据/业务应用程序

是的，但是90%以上的项目在某种程度上是这样的。没有数据是没有意义的。没有数据的演示文稿没有多大意义。

鉴于你的代表近2K在发布时，你显然可以编码。所以我建议:构建包含3个项目的解决方案。

    数据访问
  1. 业务层
  2. 。
  3. 一个只有简单类(poco)和基本对象逻辑的核心模型项目
  4. 依赖注入/控制反转

如果你非常喜欢，可以考虑4或5，而DI/IOC可能最好留到你对1/2/3/4类型的解决方案感到满意为止。

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

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

这是我可以使用MVC吗?

是的，你可以。前端项目有一个(或两个)控制器，控制器在前端项目中"调用"视图。视图只显示和获取用户的数据。控制器调用另一层。例如控制器调用业务流程层可以多次调用数据层来获取所有需要的信息并进行更新。

看看这里http://www.asp.net/mvc/tutorials如果你想知道更多关于MVC。教程并不总是"分离"干净，因为它们集中在MVC方面。事实上，您将在控制器的中间看到数据访问。这是演示者在实际项目中绝不会做的。

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

好运…

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

尝试用一些模式来编写代码，只是为了实现其中的一些模式——这不是最佳实践。不要为代码本身编写代码。尝试用最简单、清晰的方式解决业务任务，这是最好的方法。模式可以帮助你做到这一点。

你已经把代码的不同层分开了，这很好。你的架构很简单，很接近MVC。我认为你应该到此为止，不要增加复杂性。

对于DAO，它的意思是数据访问对象。没有关于数据库的任何文字。DAO可以为您提供对任何数据源的访问:数据库、缓存、nosql存储、文件、数据仓库(您的案例)等。这很好，因为你可以动态地改变你的应用程序的数据源，只要在它们之间切换，如果它们实现统一的接口。

相关文章：