如何从服务层访问EF类属性

本文关键字：EF 属性 访问 服务 | 更新日期: 2023-09-27 18:25:06

我在C#和Razor中有一个ASP.NET MVC3。应用程序的体系结构分为数据访问层（EF类+存储库）、服务层、控制器、ViewModels和View。

从我的服务层ProductServices，我调用由我的存储库ProductRepository公开的方法GetAllProducts，该方法具有以下签名：

IQueryable<Products> GetAllProducts()

因此，在ProductServices中，我调用（productRepository是ProductRepository的实例）：

var products = productRepository.GetAllProducts();

其填充变量CCD_ 7。现在我想从productServices访问产品ProductName的名称。如果我使用此指令：

var productNames = products.Select(m => m.ProductName).ToList();

我正在ServiceLayer和EF之间创建耦合（绕过存储库）。这意味着我必须向ProductRepository添加一个带有签名的方法：

IQueryable<string> GetAllProductsName()

但是，由于我在应用程序中需要其他产品信息，我是否应该在productRepository中为Product类的每个字段创建一个方法？我的推理正确吗？感谢

如何从服务层访问EF类属性

围绕这一点有两个学派，

  1. 存储库明确定义了与数据库交互的方式，并且应该受到严格控制。因此，存储库上的方法应该提供枚举的数据
  2. 存储库打破了与特定数据源类型的强耦合，但不需要提供详细和枚举的数据集

就我个人而言，我同意第二个，原因如下：

我的感觉是，当您在存储库中变得过于明确时，它会变成业务逻辑，而不是解耦机制。我真的不喜欢这样，因为这意味着您与存储库实现的联系更加紧密。

我还认为，在某些情况下，存储库不是枚举数据的合适位置，例如，我认为分页和排序是一个UI问题，但为了性能，您希望查询只与当前的页面/排序相关。这意味着您要么需要让UI参与查询编译，要么存储库需要理解分页和排序。

话虽如此，提供未枚举的数据源确实会让您在以后的工作中遇到问题，即使您确实提供了这些数据源，尽快枚举集合也是非常重要的。

如果你感兴趣，下面是我对存储库的看法：http://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html，所有代码也在github 上

您的productServices中有所有信息，因为您使用productRepository.GetAllProducts（）方法从存储库加载所有信息。如果您需要其他实体提供更多信息，则需要使用新的Service扩展您的productService。

但是，由于我的应用程序中需要其他产品信息，我应该在productRepository中为的每个字段创建一个方法吗产品类别？我的推理正确吗？感谢

在这种情况下，通常我会为服务而不是在存储库中创建Extensions方法。存储库通常有CRUD设置，仅此而已。

相关文章：