Is OData suitable for a multitasking LOB application?
I am working on a cloud business application. Users can upload documents and other types of objects to the application. Users upload quite a few documents and store several million documents together. I am using SQL Server.
Today I have several-restful-APIs that allow users to traverse a DocumentSearchQuery object where they supply the keyword along with the query sort order and paging information. They receive a back copy of the DocumentSearchResult, which is essentially a sorted collection of references to the actual documents.
Now I want to extend the search API to other entity types than docs and I am looking into using OData to do this. But it seems that if I use OData I run into problems:
- There is no built-in limit on which fields users can query, which means that either the primary will depend on whether they query the indexed field or not, or I will have to implement my own parsing of incoming OData queries so that they are indexed query fields. (Since this is a multi-tenant application and they are using physical hardware, slow requests are not very acceptable as they affect other customers.)
- Everything I use to access data in the backend must support IQueryable. I am currently using the Entity Framework which does this, but I will probably use something else in the future. This means that I feel like I need to do my own analysis of the incoming requests again.
- There is no built-in support to restrict user access to data. I need to check incoming Odata requests to make sure they are accessing data that they actually have access to access.
I don't think I want to go down the path of manually analyzing expression trees to make sure they are only trying to access the data they have access to. It seems cumbersome.
My question is, given the above, does OData use a suitable protocol in a multi-tenant environment where clients write their own clients accessing entities?
source to share
I think that fits here. Let me give you some opinions on the problems you will face:
There is no built-in limit on which fields users can query, which means that either the primary is whether they query the indexed field or not, or I'll have to implement my own parsing of incoming OData queries so that they only query indexed fields. (Since this is a multi-tier application and they exchange physical hardware, slow requests are not very acceptable as they affect other clients)
True. However, you can check the allowed fields in the filter to allow or deny the operation.
Whatever I use to access data in the backend, IQueryable needs to be supported. I am currently using the Entity Framework which does this, but I will probably use something else in the future. This means that it is likely that I need to do my own analysis of the incoming requests again.
Yes, there is a provider for EF. This means that if you are using something else in the future, you will need to write your own provider. If you change EF, you probably made your decision early. In this case, I don't recommend WCF DS.
There is no built-in support to restrict access to user data. I need to check incoming Odata requests to make sure they are accessing the data they do have permission to access.
There is no out-of-the-box support for working with WCF Data Services. However, this is part of the authorization mechanism that you will need to implement anyway. But I have good news for you: QueryInterceptors make it pretty easy. by simply intercepting the request and proceeding from user privileges. This is something that you will have to implement yourself regardless of the technology you use.
My answer. Considering the above, WCF Data Services is a suitable protocol in a multi-tenant environment where clients write their own clients, accessing entities, at least you change EF. And you have to keep in mind the enormous effort that this will save you.
source to share