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

这样对吗？哪一个

解决方案

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

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

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

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

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

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

可以将数据服务层进一步细分为组成部分(即数据访问，转换和集成)。在这种情况下，我们可能有一个"数据访问层"，只涉及检索数据，而"数据服务层"则通过数据访问层检索其数据，并将检索到的数据组合并转换为所需的各种对象。业务服务层。