“数据服务层”和“数据服务层”之间有什么区别？ 和“数据访问层”？
我记得读到过，一个将低级调用抽象到与数据无关的框架（例如 ExecuteCommand 方法等），另一个通常包含业务特定方法（例如 UpdateCustomer）。
它是否正确？ 哪个是哪个？
I remember reading that one abstracts the low level calls into a data agnostic framework (eg. ExecuteCommand methods etc), and the other usually contains business specific methods (eg. UpdateCustomer).
Is this correct? Which is which?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为一般来说这两个术语是可以互换的，但根据您的开发环境的上下文可能有更具体的含义。
数据访问层位于数据和应用程序之间的边界。 “数据”只是应用程序使用的不同数据源集。 这可能意味着必须在每个应用程序中完成大量编码，才能从多个源提取数据。 创建所需数据视图的代码在某些应用程序中是多余的。
随着数据源数量的增长并变得更加复杂，有必要隔离数据访问的各种任务，以解决数据访问、转换和集成的细节。 通过精心设计的数据服务，业务服务将能够在更高的抽象级别与数据进行交互。 处理数据访问、集成、语义解析、转换和重组以解决应用程序所需的数据视图和结构的数据逻辑最好封装在数据服务层中。
可以将数据服务层进一步分解为其组成部分（即数据访问、转换和集成）。 在这种情况下，您可能有一个仅关注检索数据的“数据访问层”，以及一个通过数据访问层检索其数据并将检索到的数据组合并转换为所需的各种对象的“数据服务层”。业务服务层。
I think in general the two terms are interchangeable, but could have more specific meanings depending on the context of your development environment.
A Data Access Layer sits on the border between data and the application. The "data" is simply the diverse set of data sources used by the application. This can mean that substantial coding must be done in each application to pull data together from multiple sources. The code which creates the data views required will be redundant across some applications.
As the number of data sources grows and becomes more complex, it becomes necessary to isolate various tasks of data access to address details of data access, transformation, and integration. With well-designed data services, Business Services will be able to interact with data at a higher level of abstraction. The data logic that handles data access, integration, semantic resolution, transformation, and restructuring to address the data views and structures needed by applications is best encapsulated in the Data Services Layer.
It is possible to break the Data Services Layer down even further into its constituent parts (i.e. data access, transformation, and integration). In such a case you might have a "Data Access Layer" that concerns itself with only retrieving data, and a "Data Service Layer" that retrieves its data through the Data Access Layer and combines and transforms the retrieved data into the various objects required by the Business Service Layer.
对我来说，这是关于您希望如何处理项目设计的个人设计决定。 有时，数据访问和数据服务是一回事。 对于.NET 和LINQ 来说就是这种情况。
对我来说，数据服务层实际上是对数据库的调用。 数据访问层接收对象并创建或修改它们以供数据服务层调用数据库。
在我的设计中，业务逻辑层根据业务规则操作对象，然后将它们传递到数据访问层，数据访问层将格式化它们以进入数据库或数据库中的对象，数据服务层处理实际的数据库调用。
To me this is a personal design decision on how you want to handle your project design. At times data access and data service are one and the same. For .NET and LINQ that is the case.
To me the data service layer is what actually does the call to the database. The data access layer receives the objects and creates them or modify them for the data service layer to make the call to the database.
In my designs the Business Logic Layer manipulates the objects based on the business rules, then passes them to the data access layer which will format them to go into the database or the objects from the database, and the data service layer handles the actual database call.
这是战壕深处的另一个视角！ 数据访问层是一个软件抽象层，它隐藏了实际获取数据的复杂性/实现。 应用程序要求数据访问层（参见 DAO 设计模式）“获取这个”或“更新那个”等（间接）。 数据访问层负责执行特定于实现的操作，例如读取/更新各种数据源，例如Oracle、MySQL、Cassandra、RabbitMQ、Redis、简单文件系统、缓存，甚至委托给另一个数据服务层。
如果所有这些工作都发生在单台计算机和同一个应用程序中，则术语数据服务层相当于服务外观（间接）。 它负责服务应用程序调用并将其委托给正确的数据访问层。
有点令人困惑的是，在分布式计算世界或面向服务的架构中，数据服务层实际上可以是充当独立应用程序的 Web 服务。 在此上下文中，数据服务层将收到的上游应用程序数据请求委托给正确的数据访问层。 在这种情况下，Web 服务从应用程序间接访问数据 - 应用程序只需要知道调用哪个服务来获取数据，因此根据经验，在分布式计算环境中，这种方法将降低应用程序的复杂性（并且总有例外情况）
所以需要明确的是，该应用程序使用 DSL 和 DAL。 应用程序中的 DSL 应与同一应用程序中的 DAL 通信。 DAL 可以选择使用单个数据源，或委托给另一个 Web 服务。 Web 服务 DSL 可以将该请求的工作委托给 DAL。 事实上，单个 Web 服务请求可以使用多个数据源来响应数据。
话虽如此，从务实的角度来看，只有当系统变得越来越复杂时，才应该更加关注架构模式。 正确地做事是很好的做法，但是不必要地给你的工作镀金是没有意义的。 还记得亚格尼吗？ 好吧，在需要的时候却无法引起共鸣！
总而言之：大卫·惠勒的一句著名格言是：“计算机科学中的所有问题都可以通过另一级间接来解决”；[1] 这句话经常被故意错误地引用，用“抽象层”代替“间接级”。 Kevlin Henney 对此的推论是：“……除了太多间接层的问题。”
Here's another perspective deep from the trenches! A Data Access Layer is a software abstraction layer which hides the complexity / implementation of actually getting the data. The applications asks the Data Access Layer (See DAO design pattern) to "get me this" or "update that" etc (indirection). The Data Access Layer is responsible for performing implementation-specific operations, such as reading/updating various data sources, such as Oracle, MySQL, Cassandra, RabbitMQ, Redis, a simple file system, a cache, or even delegate to another Data Service Layer.
If all this work happens inside a single machine and in the same application, the term Data Service Layer is equivalent to a Service Facade (indirection). It is responsible for servicing and delegating application calls to the correct Data Access Layer.
Somewhat confusingly, in a distributed computing world, or Service Oriented Architecture, a Data Service Layer can actually be a web service that acts as a standalone application. In this context, the Data Service Layer delegates received upstream application data requests to the correct Data Access Layer. In this instance, web services are indirecting data access from applications - the application only needs to know what service to call to get the data, so as a rule-of-thumb, in distributed computing environments, this approach will reduces application complexity (and there are always be exceptional cases)
So just to be clear, the application uses a DSL and a DAL. The DSL in the app should talk to a DAL in the same application. DAL's have the choice of using a single datasource, or delegate to another web service. Web Service DSL can delegate the work to the DAL for that request. Indeed, it's possible for a single web service request to use a number of data sources in order to respond to the data.
With all that said, from a pragmatic perspecive, it's only when systems become increasingly complex, should more attention be paid to architectural patterns. It's good practice to do things right, but there's no point in unnecessarily gold-plating your work. Remember YAGNI? Well that fails to resonate come the time it's needed!
To conclude: A famous aphorism of David Wheeler goes: "All problems in computer science can be solved by another level of indirection";[1] this is often deliberately mis-quoted with "abstraction layer" substituted for "level of indirection". Kevlin Henney's corollary to this is, "...except for the problem of too many layers of indirection."
数据服务层概念在 WebSphere Commerce 文档非常简单：
目前在互联网中，DSL概念主要与SOA（面向服务的架构）但不仅如此。 此处在 N 层应用程序的示例中提到。
The Data Service Layer concept done in the WebSphere Commerce documentation is straightforward:
Currently in internet the DSL concept is mainly associated with the SOAs (Service Oriented Architectures) but not only. Here is mentioned in an example of N-tier applications.