data-access-layer - “数据服务层”和“数据访问层”有什么区别？

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 服务 DSL 可以针对该请求将工作委托给 DAL。实际上，单个 Web 服务请求可以使用多个数据源来响应数据。

尽管如此，从实用的角度来看，只有当系统变得越来越复杂时，才应该更多地关注架构模式。把事情做对是个好习惯，但不必要地给你的工作镀金是没有意义的。还记得雅格尼吗？好吧，它无法在需要的时候引起共鸣！

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

Answer 4

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

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

目前在互联网中，DSL概念主要与SOA（面向服务的架构）相关联，但不仅如此。这里提到了一个 N 层应用的例子。