从 UI 层执行查询的指南
我正在尝试建立一个关于如何从 UI（控制器）层执行查询的约定。以下是我的三个选项：
- 将每个查询包装到其自己的查询对象中。 （似乎导致类爆炸，但封装更好）。
- 提供服务外观层以便将相关查询分组在一起。 （破坏 SRP 并在整个过程中散布缓存。当并非所有查询方法都需要缓存时，缓存装饰器会变得更加痛苦。）
- 提供包装 EF 或其他内容的 IDbReadContext。 （暴露了 IQueryable ，它可能会或不可能是坏的。也没有提供一点缓存，因为多个对象可以运行相同的查询。
任何指导或建议都会很棒！
I'm trying to establish a convention on how to execute queries from our UI (controllers) layer. Here are my three options:
- Wrap each query into its own query object. (seems to lead to class explosion but better encapsulation).
- Provide a service facade layer in order to group related queries together. (breaks SRP and sprinkles caching throughout. caching decorator makes more painful when not all query methods need caching.)
- Provide an IDbReadContext that wraps EF or whatever. (exposes IQueryable which could or couldn't be bad. also gives no one point of caching since multiple objects could be running the same queries.
Any guidance or suggestions would be great!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我倾向于每个查询使用一个类，因为我发现它有几个优点。每个查询类更好地遵循单一责任原则，但也更好地遵循开放封闭原则 - 当每个查询都封装在自己的类中时，通过添加新代码而不更改现有代码，可以更轻松地在系统中进行更改。当每个查询都是它自己的类时，使用面向方面的技术系统地应用横切行为（例如日志记录、授权和缓存）也更容易。
有时，我会设计一个具有多个重载的查询类，用于使用不同的参数集调用查询，但只有当结果在逻辑上相同（仅从稍微不同的上下文中检索）时我才尝试这样做 - 之间的可重用性数量过载是磨砺的良好指示
I tend to use a class per query, as I find several advantages to it. Each query class follows the single responsibility principle better, but also follows the open-closed principle better as well - it is easier to make changes in a system by adding new code and not changing existing code when each query is encapsulated in its own class. It is also easier to systematically apply cross-cutting behaviors like logging, authorization, and caching using aspect-oriented techniques when each query is its own class.
On occasion, I will design a single query class with multiple overloads for calling the query with different sets of parameters, but I try to do this only when the result is logically the same only retrieved from slightly different contexts - the amount of reusability between the overloads is a good indication of whet