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

Question

我记得读到过将低层调用抽象成数据无关框架(例如ExecuteCommand方法等)，而另一个通常包含特定于业务的方法(例如UpdateCustomer)。

这正确吗？哪个是哪个？

- ilitirit

Answer 1

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

对我来说，数据服务层实际上是调用数据库的一部分。数据访问层接收对象并创建或修改它们，以便数据服务层可以调用数据库。

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

- Longhorn213

Answer 2

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

数据访问层位于数据和应用程序之间的边界。 "数据"仅是应用程序使用的各种数据源。这意味着每个应用程序都必须进行大量编码才能从多个源中汇集数据。创建所需数据视图的代码将在某些应用程序中重复。

随着数据源数量的增加和变得更加复杂，需要将数据访问的各种任务隔离以解决数据访问、转换和集成的细节问题。通过设计良好的数据服务，业务服务 将能够以更高级别的抽象与数据交互。处理数据访问、集成、语义解析、转换和重新构造以满足应用程序所需的数据视图和结构的数据逻辑最好封装在数据服务层中。

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

- pdavis

Answer 3

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

如果所有这些工作都发生在同一台机器和同一应用程序内，数据服务层的术语等同于服务门面（间接）。它负责为应用程序调用提供服务并委派到正确的数据访问层。

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

因此，为了明确起见，应用程序使用DSL和DAL。应用程序中的DSL应该与同一应用程序中的DAL通信。 DAL可以选择使用单个数据源，也可以委派给另一个Web服务。 Web服务DSL可以将工作委派给该请求的DAL。实际上，一个单独的Web服务请求可能使用多个数据源来响应数据。

尽管如此，从务实的角度来看，只有当系统变得越来越复杂时，才应更加关注架构模式。做正确的事是好习惯，但没有必要让你的工作过于复杂。记住YAGNI吗？那在需要的时候就无法产生共鸣！

最后：David Wheeler的著名格言是：“计算机科学中的所有问题都可以通过另一级间接性来解决”；[1]这经常被故意曲解为“抽象层”代替“间接性”。Kevlin Henney对此的推论是，“...除了太多层间接性的问题。”

- KRK Owner

Answer 4

在WebSphere Commerce文档中，Data Service Layer的概念很简单：

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

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

- user2751320