问哪一层包含用于读取的查询？

EN

我不熟悉ESHOPONWEB又名eShopOnWeb，这是微软发布的参考架构和实现，但我看到它有一个附带的eBook，其中包括一个“架构原则”部分，另一个关于“通用web应用程序架构”的部分，其他部分一目了然地解释了架构的更多细节。

使用这本书和代码应该会给你一个很好的方法，让你按照自己的节奏学习相关概念。

哪一层应该包含原生查询？

我不是百分之百确定你所说的“原生查询”是什么意思。我在eBook中进行了快速搜索，没有看到任何明显的引用。

典型的最佳实践体系结构(如eBook中的体系结构)表示，应用程序/业务逻辑层中的查询应该是不可知的-这意味着它们不应该包含将业务逻辑与特定数据访问提供程序紧密耦合的任何代码或依赖项。

因此，如果需要查询数据库，特定于数据库的查询代码(或对数据库中存储过程的引用或任何其他特定于数据库的概念)应该在数据访问代码中，而数据访问代码位于数据访问(基础架构)层中。

如果您的业务逻辑层中的某个对象想要执行查询，那么脑海中会浮现出三种方法：

，，

1. ，

，

1. ，

，

1. ，它想要查询自己，这是自由的，使用不可知的代码，针对已有的对象，它想要从数据库中查询数据，它获得了数据访问权限。查询输入和结果需要在这些层之间不可知地传输。例如，查询结果可能以数据传输对象的集合/数组/列表的形式返回。
2. 您从数据库/数据访问层获取数据的一部分，将其预加载为业务逻辑层中的数据库不可知数据模型，它可以像#1一样查询。

我不确定，但是你的域层可能是，你可以用它来做#3？

这有意义吗?回答了你的问题吗？

关于层的

正如eShopOnWeb一书中所解释的，您希望保持各种“关注点”(如业务逻辑、UI和数据访问全部分离)。这种分离是为了使维护和更改更容易管理，特别是在很长一段时间内。例如：

• 将业务逻辑层/代码与UI层/代码分开意味着您应该能够添加新类型的UI，而不必重新编写应用程序code.
• Keeping业务逻辑层/代码与数据访问层/代码分开意味着您应该能够添加/交换数据提供程序(例如，不同类型的数据库)，并且业务逻辑应该不会受到数据库更改的影响。

在上面的两点中，我说“应该”，因为这取决于你的分离有多干净和有效。

将其转换为您的层，UI显然是您的表示层，业务逻辑听起来像您的应用程序层和域层，数据访问是您的基础架构层。

在eBook中，他们给出了一个例子(图5-1，第16页)，其中逻辑上有你使用的四层，但在一个代码库/包中(它将全部部署在一起)。