3

我正在开发基于云的业务线应用程序。用户可以将文档和其他类型的对象上传到应用程序。用户上传了相当多的文档，总共存储了数百万个文档。我使用 SQL Server。

今天我有一个有点安静的 API，它允许用户传入一个 DocumentSearchQuery 实体，他们在其中提供关键字以及请求排序顺序和分页信息。他们返回一个 DocumentSearchResult，它本质上是对实际文档的引用的排序集合。

我现在想将搜索 API 扩展到文档以外的其他实体类型，并且我正在研究为此使用 OData。但我的印象是，如果我使用 OData，我将面临几个问题：

  • 用户可以查询的字段没有内置限制，这意味着性能将取决于他们是否查询索引字段，或者我必须自己解析传入的 OData 请求以确保它们只查询索引字段. （因为它是一个多租户应用程序并且它们共享物理硬件，所以慢查询是不可接受的，因为这会影响其他客户）
  • 无论我使用什么来访问后端数据都需要支持 IQueryable。我目前正在使用执行此操作的实体框架，但将来我可能会使用其他东西。这意味着我可能需要再次自己解析传入的查询。
  • 没有内置支持限制用户可以访问的数据。我需要验证传入的 Odata 查询，以确保他们访问他们实际上有权访问的数据。

我认为我不想走手动解析传入表达式树的道路，以确保他们只尝试访问他们有权访问的数据。这似乎很麻烦。

我的问题是：考虑到上述情况，在客户编写自己的客户端访问实体的多租户环境中使用 OData 是否是一种合适的协议？

4

1 回答 1

1

我觉得这里很合适。让我给你一些关于你认为你将面临的问题的意见：

用户可以查询的字段没有内置限制，这意味着性能将取决于他们是否查询索引字段，或者我必须自己解析传入的 OData 请求以确保它们只查询索引字段. （因为它是一个多租户应用程序并且它们共享物理硬件，所以慢查询是不可接受的，因为这会影响其他客户）

真的。但是，您可以检查过滤器中的允许字段以允许或拒绝操作。

无论我使用什么来访问后端数据都需要支持 IQueryable。我目前正在使用执行此操作的实体框架，但将来我可能会使用其他东西。这意味着我可能需要再次自己解析传入的查询。

是的，有 EF 提供商。这意味着如果您将来使用其他东西，您将需要编写自己的提供程序。如果您更改 EF，您可能会提前做出决定。在这种情况下，我不推荐 WCF DS。

没有内置支持限制用户可以访问的数据。我需要验证传入的 Odata 查询，以确保他们访问他们实际上有权访问的数据。

对 WCF 数据服务没有任何开箱即用的支持来做到这一点。但是，这是您无论如何都需要实施的授权机制的一部分。但我要告诉你一个好消息：使用 QueryInterceptors 很容易做到。简单地拦截查询，并根据用户权限。这是您必须根据您使用的技术独立实施的事情。

我的回答：考虑到上述情况，WCF 数据服务是多租户环境中的合适协议，在该环境中，客户编写自己的客户端访问实体，至少您更改 EF。你应该记住它为你节省的巨大努力。

于 2013-01-26T23:00:33.063 回答