开始返回 IQueryable的时间而不是 IList;到我的 Web UI / Web API 层?

发布于 2024-08-27 01:17:56 字数 608 浏览 9 评论 0原文

我有一个多层应用程序,它从所有数据访问的存储库模式开始,并将 IQueryable 返回到服务层。包含所有业务逻辑的服务层将 IList 返回到控制器(注意:我在 UI 层使用 ASP.NET MVC)。在数据访问层返回 IQueryable 的好处是,它使我的存储库变得非常简单,并且可以推迟数据库查询。但是,我在服务层中触发数据库查询,以便我的单元测试更加可靠,并且我不会为控制器提供灵活性来重塑我的查询。然而,我最近遇到了几种情况,将查询的执行推迟到控制器会显着提高性能,因为控制器必须对特定于 UI 的数据进行一些预测。此外,随着 oData 等事物的出现,我开始怀疑端点(例如 Web UI 或 Web API)是否应该直接与 IQueryable 一起工作。你有什么想法?是时候开始将 IQueryable 从服务层返回到 UI 层了吗?还是坚持使用 IList?

此线程位于:要返回 IQueryable;或不返回 IQueryable似乎可以保证将 IList 返回到 UI 层,但我想知道事情是否会因为新兴技术和技巧而发生变化。

I've got a multi-layer application that starts with the repository pattern for all data access and it returns IQueryable to the Services layer. The Services layer, which includes all of the business logic, returns IList to the Controllers (note: I'm using ASP.NET MVC for the UI layer). The benefit of returning IQueryable in the data access layer is that it allows my repositories to be extremely simple and the database queries to be deferred. However, I'm triggering the database queries in my services layer so that my unit tests is more reliable and I don't give flexibility to the Controllers to reshape my queries. However, I've recently encountered several situations where deferring the execution of queries down to the Controllers would have been significantly more performant because the Controllers had to do some projections on the data that was UI specific. Additionally, with the emergence of things like oData, I was starting to wonder if end points (e.g. web UI or web apis) should be working directly with IQueryable. What are your thoughts? Is it time to start returning IQueryable from the services layer to the UI layer? Or stick with IList?

This thread here: To return IQueryable<T> or not return IQueryable<T>
seems to vouch for returning IList to the UI layers, but I was wondering if things are changing because of new emerging technologies and techniques.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

他不在意 2024-09-03 01:17:56

我喜欢尽可能坚持使用 IQueryable 接口,唯一的问题是当您最终在控制器级别按需进行复杂的过滤或重新查询时,如果您有类似的操作:

//DATA ACCESS
    public IQueryable<T> GetStudents()
    {
    return db.Students;
    }

并且在控制器中进行了一些重新锐化,因为您的客户想要过滤该结果的一些数据,您肯定会想在控制器级别执行此操作:

var result = obj.GetStudents().Where(d=>d...);

对我来说,这是可以的,但只要想象一下,如果任何其他模块需要使用相同的过滤器,您就不能调用它,因为它在控制器级别。
所以对我来说,这是 DRY、灵活性和系统可扩展性之间的平衡。
如果您需要一个完全可扩展的系统,您将需要对 GetStudents() 方法进行一些或多次重载,并消除控制器级别的任何重新锐化。

I like to stick with the IQueryable Interface when possible, the only problem is when you end up doing complex filtering or re-query on demand at the Controller level, if you have something like:

//DATA ACCESS
    public IQueryable<T> GetStudents()
    {
    return db.Students;
    }

And in your controller you do some re-sharping because your client want to filter some data of that result, surely you will be tempted to do it at the controller level:

var result = obj.GetStudents().Where(d=>d...);

and for me its ok, but just imaging if any other module need to use that same filter, you cant call it because its on the controller level.
So for me its a thing of balance between DRY, flexibility, and how scalable is the system.
If you need a fully scalable system you will need to do some or several overloads to GetStudents() method and get rid of any re-sharping at the controller level.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文