如何从业务逻辑中分离远程数据访问（通过http）逻辑？

我很好奇什么才是在以下实现中使用的最佳设计模式：我创建了一个小型应用程序，用于从网站下载图像并将其设置为我的背景。如何从业务逻辑中分离远程数据访问（通过http）逻辑？

我想与网站进行接口以下载XML Background.xml文件，并下载另一个文件（Background.bmp），该文件位于此远程服务器上。该文件是位图，XML是关于位图的元数据。我下载文件后，我想将其设置为我的背景。我想从背景设置代码中分离出文件下载代码，但我不确定我会使用哪种设计模式。

这似乎是一个典型的演示/数据/业务应用程序，其中Form是表示层，背景设置器/ 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(); 
    } 
}

何我会将数据访问部分与背景设置逻辑分开吗？

来源

2013-05-01 Ian R. O' Brien

我很好奇，什么是最好的设计模式在使用下面的实现

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

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

我想将文件从背景设置代码下载代码中分离出来，但我不知道我会用它的设计模式。

为什么？是的，这是很好的做法，但有理由分开。 a）将所有代码放在一个方法中是一个极端。这个方法是一个极端的方法。 b）在班级中使用许多方法。升级
c）下一步在项目中分开课程。基本OO
d）在解决方案中制作单独的项目。更多的设计模式
e）建立沟通的独立解决方案。另一个极端。

你很可能在看C）或D），因为你喜欢应用设计原则。

您选择的选项可以有自己的变体，例如依赖注入/控制模式的反转。但即时通讯建议你不要试图在前面做这件事。听起来像你的应用程序的矫枉过正。

这似乎是一个典型的表现/数据/业务应用

是确实的，但项目的90％以上会以某种方式。有没有多少点数据你不出席。没有数据的演示文稿没有多少意义。

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

数据访问
业务层
演示文稿。
只需简单类（波苏斯）和基本对象的逻辑
依赖注入/控制

考虑4或5只有非常热衷，并且DI的反转的核心示范项目/ IOC可能是最好的左直到您对1/2/3/4类型解决方案感到满意为止。

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

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

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

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

如果您想了解更多关于MVC的信息，请点击这里http://www.asp.net/mvc/tutorials。这些教程并不总是“干净地”分开，因为他们专注于MVC方面。 Infact您将在控制器中看到数据访问。出席者在实际项目中永远不会做的。

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

好运...

来源

2013-05-01 13:20:16

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

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

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

关于DAO，它表示数据访问对象。没有关于数据库的任何词。 DAO可以为您提供对任何数据源的访问：数据库，缓存，nosql存储，文件，数据仓库（您的案例）等。这非常棒，因为您可以动态更改应用程序的数据源，只需在它们之间进行切换。

来源

2013-05-01 08:49:53

如何从业务逻辑中分离远程数据访问（通过http）逻辑？

回答

相关问题