使用Web API进行过滤

Question

我有一个带有多个Web API控制器的应用程序，现在我有一个要求，该要求是能够按对象属性筛选GET结果。我一直在考虑使用OData，但由于以下几个原因，我不确定它是否合适：

1. Web API控制器无法直接访问DataContext，而是通过“域”层从数据库中获取数据，因此无法查看我们的实体框架模型。
2. 在第一项中，Web API处理在域层中生成的轻量级DTO模型对象。这实际上是隐藏EF模型的原因。这里的问题是我希望这些查询在我们的数据库中执行，但是到Web API方法从域层获取集合时，集合中的所有对象都已映射到这些DTO对象，所以我看不到以这种方式将对象从EF中一次删除后，OData筛选器如何可能完成其工作。
3. 这一项可能是最重要的一项：我们真的不想允许对我们的Web API /数据库进行任意查询。我们只是想利用这个OData库来避免编写我们自己的过滤器，并为可能由我们的Web API端点之一返回的每种类型的对象过滤过滤器/构建器。

我基于＃3进入错误的轨道了吗？如果没有，我们是否可以使用此OData库而无需大量重构Web API和EF的交互方式？

Answer 1

我还没有OData的经验，但是从我的眼中可以看出，它是为Context提供的，旨在管理这些模型的交互和返回。我绝对不喜欢以任何形式将实体返还给客户。

这是一个丑陋的情况，但是面对这种情况，我的第一个行动方案是推回客户以证明其搜索需求的合理性。默认请求几乎总是“好吧，能够对所有内容进行搜索会很好。”我的回答是，我不想知道你想要什么，我想知道你需要什么，因为我不想给你装满枪的枪，用自己的脚砸掉然后又怪我，因为系统停止运转。如果搜索过于开放，搜索将是巨大的性能杀手。当用户仅需要25％的情况时，就很难测试准确性/相关性，并且无法有效地为100％的可能搜索案例建立索引。如果客户不能告诉您他们将需要什么搜索，而只是因为他们可能需要它们而只想要一切，那么他们就不需要了。

我个人坚持使用特定的搜索DTO，并将其转换为linq表达式。

如果我面临实施这样的硬性要求，我会：

1. 尝试从与实时数据库同步的报告副本中推送这些搜索/报告。 （为了最大程度地减少一些白痴经理在启动一些古怪的未索引搜索条件时的工作量，以便它不会占用人们尝试工作的生产数据库。）
2. 创建一个新的有界DbContext，专门用于使用单独的实体定义进行搜索，该实体定义仅公开最小数量的属性以表示搜索条件和ID。
3. 将此有界上下文连接到API和OData中。它将返回“搜索结果”。当用户选择搜索结果时，请针对API使用ID来加载适用的域或启动操作等。

不。 1.是可选的，很高兴提供给他们，使他们可以在不被“看到”更新的条件（直到被复制）之前进行搜索。 （即几秒钟到几分钟不等，具体取决于复制策略/大小）这些搜索通常用于报表类型的查询，因此我会尽量将其与用户使用的常规日常搜索选项区分开。 （即高级搜索选项等）。