如何从服务层访问 EF 类属性
我有一个 C# 和 Razor 中的 ASP.NET MVC3。应用程序的架构分为数据访问层（EF 类 + 存储库）、服务层、控制器、视图模型和视图。
从我的服务层 ProductServices 中，我调用由我的存储库 ProductRepository 公开的方法 GetAllProducts ，该方法具有以下签名：
IQueryable<Products> GetAllProducts()
因此在 ProductServices< /code> 我调用（productRepository 是 ProductRepository 的一个实例）：
var products = productRepository.GetAllProducts();
填充变量 products。现在我想从 productServices 访问产品 ProductName 的名称。如果我使用此指令：
var productNames = products.Select(m => m.ProductName).ToList();
我将在 ServiceLayer 和 EF 之间创建耦合（绕过存储库）。这意味着我必须向 ProductRepository 添加一个带有签名的方法：
IQueryable<string> GetAllProductsName()
但是，由于我的应用程序中需要其他产品信息，我是否应该在 productRepository 中为每个字段创建一个方法？ 产品类？我的推理正确吗？谢谢
I have an ASP.NET MVC3 in C# and Razor. The architecture of the application is divided in Data Access Layer (EF classes + Repository), Service Layer, Controller, ViewModels and View.
From my Service Layer ProductServices I call the method GetAllProducts exposed by my Repository ProductRepository , which has the following signature:
IQueryable<Products> GetAllProducts()
Therefore within ProductServices I call (productRepository is an instance of ProductRepository):
var products = productRepository.GetAllProducts();
that populates the variable products. Now I would like to access the name of the product ProductName from productServices. If I use this instruction:
var productNames = products.Select(m => m.ProductName).ToList();
I am creating coupling between ServiceLayer and the EF (bypassing the repository). That means I must add to ProductRepository a method with signature:
IQueryable<string> GetAllProductsName()
However, since I need other product information in my application, shall I create one method in productRepository for each field of the Product class? Is my reasoning correct? Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对此有两种观点：
就我个人而言，我赞成第二个，原因如下：
我的感觉是，当您在存储库中变得过于明确时，它就会变成业务逻辑而不是解耦机制。我不太喜欢这个，因为这意味着您与存储库实现的联系更加紧密。
我还认为，在某些情况下，存储库不是枚举数据的正确位置，例如，我认为分页和排序是 UI 问题，但是为了性能，您希望查询仅与当前页面/排序相关。这意味着您要么需要让 UI 参与查询编译，要么存储库需要了解分页和排序。
话虽如此，提供未枚举的数据源确实会让您在以后遇到问题，即使您确实提供了它们，尽快枚举该集也非常重要。
如果您有兴趣，这是我对存储库的看法： http ://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html，所有代码也在github上
Theres two schools of thought around this,
Personally i subscribe to the second, heres why:
my feeling is that when you get overly explicit within the repository it turns into business logic rather than a decoupling mechanism. I don't really like this as it means that you become more tightly linked to the repository implementation.
I also think that in some cases the repository isnt the right place to enumerate the data, for example I believe paging and sorting is a UI concern, however for performance you want queries to only relate to the current page/sort. this means you either need to let the UI contribute to the query compilation or the repository needs to understand paging and sorting.
Having said that providing un-enumerated datasources does open you up for issues later down the track, and even if you do provide them its very important to enumerate the set as soon as possible.
If you're interested heres my take on the repositories: http://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html , all the code is also on github
您的productServices 中拥有所有信息，因为您使用productRepository.GetAllProducts() 方法从存储库加载了所有信息。如果您需要来自其他实体的更多信息，那么您需要使用新服务来扩展您的产品服务。
在这种情况下，通常我会为服务创建扩展方法，而不是在存储库中。存储库通常只有 CRUD 设置，仅此而已。
You have all information in your productServices because you load all information from your Repository with the method productRepository.GetAllProducts(). If you need more information from an other entity then you need to extend your productServices with a new Service.
In this situation normally I create Extensions method's for the service and not in the repository. The Repository have normally a CRUD Setup and nothing more.