问题描述
我正在研究基于云的业务应用程序.用户可以将文档和其他类型的对象上载到应用程序.用户上传了大量文档，并且总共存储了数百万个文档.我使用SQL Server.
I'm working on a cloud-based line of business application. Users can upload documents and other types of object to the application. Users upload quite a number of documents and together there are several million docs stored. I use SQL Server.
今天，我有一个稍微有些放松的API，它允许用户传递一个DocumentSearchQuery实体，他们在其中提供关键字以及请求排序顺序和分页信息.他们返回一个DocumentSearchResult，本质上是对实际文档的引用的排序集合.
Today I have a somewhat-restful-API which allow users to pass in a DocumentSearchQuery entity where they supply keyword together with request sort order and paging info. They get a DocumentSearchResult back which is essentially a sorted collection of references to the actual documents.
我现在想将搜索API扩展到文档以外的其他实体类型，并且我正在为此考虑使用OData.但是，我的印象是，如果使用OData，我将面临几个问题:
I now want to extend the search API to other entity types than documents, and I'm looking into using OData for this. But I get the impression that if I use OData, I will face several problems:
- 用户可以查询哪些字段没有内置限制，这意味着性能将取决于他们是否查询索引字段，或者我将不得不对传入的OData请求实施自己的解析以确保仅查询索引字段. (由于它是一个多租户应用程序，并且它们共享物理硬件，因此缓慢的查询实际上是不可接受的，因为它们会影响其他客户)
- 无论我在后端使用什么访问数据，都需要支持IQueryable.我目前正在使用执行此操作的Entity Framework，但将来可能会使用其他功能.这意味着我可能需要再次对传入的查询进行自己的解析.
- 没有内置的支持来限制用户可以访问的数据.我需要验证传入的Odata查询，以确保它们访问他们实际上有权访问的数据.
我不认为我要手动解析传入的表达式树以确保它们仅尝试访问自己有权访问的数据.这似乎很麻烦.
I don't think I want to go down the road of manually parsing incoming expression trees to make sure they only try to access data which they have access to. This seems cumbersome.
我的问题是:考虑到以上情况，在多租户环境中使用OData是否是合适的协议，在这种环境中，客户编写自己的客户端来访问实体?
My question is: Considering the above, is using OData a suitable protocol in a multi-tenant environment where customers write their own clients accessing the entities?
推荐答案
我认为这里很合适.让我对您认为将要面对的问题发表一些意见:
I think it is suitable here. Let me give you some opinions about the problems you think you will face:
是的.但是，您可以在过滤器中检查允许的字段，以允许操作或拒绝操作.
True. However you can check for allowed fields in the filter to allow the operation or deny it.
是的，有EF提供商.这意味着，如果将来使用其他东西，则需要编写自己的提供程序.如果您更改EF，则可能要早日做出决定.在这种情况下，我不建议使用WCF DS.
Yes, there is a provider for EF. That means if you use something else in the future you will need to write your own provider. If you change EF probably you took a decision to early. I don´t recommend WCF DS in that case.
使用WCF数据服务没有开箱即用的支持，对.但是，这是您仍然需要实现的授权机制的一部分.但我对您有个好消息:使用QueryInterceptors可以很容易地做到这一点.只需根据用户权限拦截查询即可.这是您必须独立使用所使用的技术来实现的方法.
There isn´t any out-of-the-box support to do that with WCF Data Services, right. However that is part of the authorization mechanism that you will need to implement anyway. But I have good news for you: do it is pretty easy with QueryInterceptors. simply intercepting the query and, based on the user privileges. This is something you will have to implement it independently the technology you use.
我的答案:考虑到上述情况，WCF数据服务是多租户环境中的一种合适协议，在这种环境中，客户至少编写了自己的客户端来访问实体，至少您需要更改EF.而且您应该记住它为您节省的大量精力.
My answer: Considering the above, WCF Data Services is a suitable protocol in a multi-tenant environment where customers write their own clients accessing the entities at least you change EF. And you should have in mind the huge effort it saves to you.
这篇关于OData是否适合多租户LOB应用程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！