Ist es auch eine gute Idee, OData zu verwenden?

8

Wenn wir im Voraus verstehen, dass "nur weil eine Fähigkeit angeboten wird, macht es keine gute Idee" ...

Aus der Sicht der OData-konformen Signaturen müssen Sie zurückkehren IQueryable .

BEISPIEL:

%Vor%

Jedoch beschreiben viele Artikel in der jüngsten und nicht so jüngsten Vergangenheit IQueryable als:

  • Undicht
  • ' Causing Heavy Lifting " Beispiel: ermöglicht Benutzern, ganze Tabelle (n) zu greifen
  • Hat Sicherheit & amp; Probleme bei der Skalierung, da eine starke Änderung der Abfrage selbst ermöglicht
  • Kann auch Probleme durch verzögerte Ausführung verursachen (wegen seiner abfragbaren Art)

Meine Frage ist :
Haben Sie das Gefühl, dass die Fähigkeiten von IQueryable und OData die obigen Probleme übertreffen?

Bei der Beantwortung würde ich erwarten, dass die Leute darüber sprechen:

  • Warum oder warum nicht?
  • Wann sollte ich es verwenden?
  • Verwenden Sie nur einige WebAPI-Aufrufe ... oder alle WebAPI-Aufrufe?
  • Was ist mit einzelnen Modellen, die keine IEnumerable-Objekte sind?

... solche Sachen.

HINTERGRUND : Ich frage nicht nur wegen der oben aufgeführten Punkte. Aber auch, weil OData an uns als "Industriestandard" und nicht als Tool in Ihrer Toolbox verkauft wird. Die Implementierung würde also die Rendite für unsere WebAPI-Aufrufe (wo ich zurzeit arbeite) grundlegend ändern. Wir müssten von unserer eigenen IResult-Rücksignatur (die sehr nützlich ist) zu IQueryable wechseln, die Probleme zu haben scheint (aber auch nützlich sein kann).

IRESULT-BEISPIEL:
Zumindest würden sich unsere Rücksignaturen drastisch ändern. Und mir wurde gesagt, WebAPI-Aufruf, der OData implementiert, funktioniert nicht, indem "C Instance" in "IQueryable Instance" geändert wird (was sinnvoll ist).

%Vor%     
Prisoner ZERO 13.03.2013, 16:10
quelle

1 Antwort

3

Wenn Sie die OData-Abfrage mit der Web-API unterstützen, benötigen Sie kein IQueryable<T> . Mit IQueryable<T> können Sie schneller und mit weniger Code dorthin gelangen. IQueryable<T> verfügt über die erforderlichen Abstraktionen, um eine eingehende OData-Abfrage in eine LINQ-Abfrage zu übersetzen. Das Framework definiert es bereits und es gibt eine reiche Unterstützung über verschiedene Backends wie Entityframework, NHibernate, Linq2Objects, RavenDB, Linq2OData usw. Also haben wir uns entschieden, reichhaltige Unterstützung für IQueryable<T> mit Web-API zu haben. Vereinbart, IQueryable<T> ist eine riesige Schnittstelle und macht viel mehr frei, als für die OData-Abfrage notwendig ist. Aber es ist etwas, das kostenlos ist :).

Das heißt, wir haben eine gute Unterstützung durch ODataQueryOptions<T> für nicht-iQueryable-Fall. Schau dir meinen Blog-Eintrag dazu an hier

Außerdem verwechseln Sie die OData-Abfragesemantik mit OData. Rich-Query-Unterstützung ist nur ein Teil von OData. OData baut auf HTTP auf und hat verschiedene nützliche Funktionen wie

  • Eine durchdachte Anwendung der Best Practices von REST und HTTP.
  • Eindeutige Darstellungen Ihrer Ressourcen in json und xml.
  • $ Metadaten.
  • Eine Standardmethode zur Beschreibung von Beziehungen.
  • Umfangreiche Abfragen, die Projektionen, Filterung, Client-gesteuertes Paging und serverseitiges Paging (Link der nächsten Seite) unterstützen.
  • Großes Ökosystem .
RaghuRam Nadiminti 13.03.2013, 20:47
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset C # Beispiel des programmatischen Herunterladens von GitHub privaten Repos