“数据服务层”和“数据访问层”之间有什么区别？

Question

我记得读过那个将低级别调用抽象为数据无关框架（例如ExecuteCommand方法等），另一个通常包含业务特定方法（例如，UpdateCustomer）。

这是对的吗？哪个是哪个？

Answer 1

对我来说，这是一个关于如何处理项目设计的个人设计决策。有时数据访问和数据服务是同一个。对于.NET和LINQ就是这种情况。

对我而言，数据服务层实际上是对数据库的调用。数据访问层接收对象并创建它们或修改它们以供数据服务层调用数据库。

在我的设计中，业务逻辑层根据业务规则操作对象，然后将它们传递给数据访问层，数据访问层将格式化它们以进入数据库或数据库中的对象，数据服务层处理实际的数据库调用。

Answer 2

我认为一般来说这两个术语是可以互换的，但根据开发环境的上下文可能有更具体的含义。

数据访问层位于数据和应用程序之间的边界上。 “数据”只是应用程序使用的各种数据源。这可能意味着必须在每个应用程序中进行大量编码，以便从多个源中将数据拉到一起。创建所需数据视图的代码在某些应用程序中将是多余的。

随着数据源数量的增长和变得越来越复杂，有必要隔离数据访问的各种任务，以解决数据访问，转换和集成的细节问题。借助精心设计的数据服务，业务服务将能够以更高的抽象级别与数据进行交互。处理数据访问，集成，语义解析，转换和重构以处理应用程序所需的数据视图和结构的数据逻辑最好封装在数据服务层中。

可以将数据服务层进一步分解为其组成部分（即数据访问，转换和集成）。在这种情况下，您可能拥有一个仅涉及检索数据的“数据访问层”，以及一个通过数据访问层检索其数据的“数据服务层”，并将检索到的数据组合并转换为所需的各种对象。业务服务层。

Answer 3

这是战壕深处的另一个视角！数据访问层是一个软件抽象层，它隐藏了实际获取数据的复杂性/实现。应用程序要求数据访问层（参见DAO设计模式）“让我这个”或“更新那个”等（间接）。数据访问层负责执行特定于实现的操作，例如读取/更新各种数据源，例如Oracle，MySQL，Cassandra，RabbitMQ，Redis，简单文件系统，缓存，甚至委托给另一个数据服务层。

如果所有这些工作都发生在单个机器和同一个应用程序中，则术语数据服务层等同于服务外观（间接）。它负责将应用程序调用服务和委派给正确的数据访问层。

有点令人困惑的是，在分布式计算世界或面向服务的体系结构中，数据服务层实际上可以是充当独立应用程序的Web服务。在此上下文中，数据服务层将接收到的上游应用程序数据请求委托给正确的数据访问层。在这种情况下，Web服务正在间接来自应用程序的数据访问 - 应用程序只需要知道要调用哪些服务来获取数据，因此，作为一种经验法则，在分布式计算环境中，这种方法将降低应用程序的复杂性（以及总有例外情况）

因此，为了清楚起见，该应用程序使用DSL和DAL。应用程序中的DSL应与同一应用程序中的DAL通信。 DAL可以选择使用单个数据源，也可以委托给其他Web服务。 Web Service DSL可以将工作委托给该请求的DAL。实际上，单个Web服务请求可能会使用大量数据源来响应数据。

尽管如此，从务实的角度来看，只有当系统变得越来越复杂时，才应该更多地关注架构模式。做正确的事情是一种很好的做法，但是对你的工作进行不必要的镀金是没有意义的。还记得YAGNI吗？好吧，在需要它的时候没有产生共鸣！

总结：David Wheeler的一句名言：“计算机科学中的所有问题都可以通过另一层次的间接解决”; [1]这通常是故意错误引用“抽象层”代替“等级”间接”。 Kevlin Henney对此的推论是，“......除了太多间接层的问题。”

Answer 4

WebSphere Commerce文档中的数据服务层概念非常简单：

  

数据服务层（DSL）为数据访问提供了一个独立于物理模式的抽象层。   数据服务层的目的是提供一个用于访问数据的一致接口（称为数据服务外观），独立于对象关系映射框架

目前在互联网上， DSL 概念主要与 SOA （面向服务的体系结构）相关联，但不仅如此。在N层应用程序的示例中提到了Here。