Wie kann man bei OData das $filter-Attribut einschränken & wie löst man das Mapping auf Entities?

Ich habe noch nicht mit OData gearbeitet und auch noch kein Service direkt verwendet, der OData unterstützt (also wahrscheinlich indirekt mit irgendwelchen Azure Client Libraries), bin aber daran interessiert, wie ihr das mit dem $filter handelt.

Bisher hatte ich Service Methoden, dich ich 100% kontrollieren konnte. Das heißt ich kenne die verschiedenen Optionen und kann den kompletten Kontrollfluss kontrollieren. Zum Beispiel Datenbankabfragen optimieren. Mit OData kommt viel Flexibilität ins Spiel und damit auch die Gefahr, dass sehr langsame Abfragen abgesetzt werden müssen.

Grenzt Ihr die Filter Möglichkeiten so ein, dass ihr nur Abfragen ermöglicht, die unproblematisch sind oder lebt ihr einfach mit dem Risiko?

Wie löst ihr das Mapping auf die Datenbank? In diesem Thread scheint es auch keine richtig gute Antwort zu geben: oData und die 3-Schichten-Architektur

Hallo malignate,

du kannst die Attribute im OData schon ein wenig einschränken. Schau mal hier:

Protect your Queryable API with the validation feature in ASP.NET Web API OData

Nicht nur das $filter-Attribut.

Gruss

Coffeebean

Einschränkung eben über das von Coffeebean genannte Attribut und das Mapping entweder über einen eigenen Expression Parser oder über den ODataQueryOptionParser.

Hier mal der erste Treffer bzgl. des ODataQueryOptionParsers.
How do I map an OData query against a DTO to another entity?

Klar, kann man. Aber danach habe ich gar nicht gefragt. Google benutzen kriege ich schon einigermaßen hin 😉. Vielleicht habe ich mich aber auch ein bisschen unklar ausgedrückt.

Ich hatte auf Erfahrungsberichte gehofft, z.B.

1. Habt ihr OData mit einem Data Provider verwendet, der kein Linq unterstützt? Wie groß ist dabei der Aufwand?
2. Habt ihr OData mit einem dynamischen Model verwendet und wie ist eure Erfahrung?
3. Wie groß ist die Adaption von OData? Wie außerhalb des MS Umfelds?
4. Wie stark musstet ihr OData einschränken?
5. Hattet ihr schon mal Probleme im Produktionsbetrieb weil Abfragen zu lange gedauert haben?
6. ...

Mir sind die Implikationen von OData noch nicht ganz klar. Und der Aufwand und Komplexität um einen guten Abstraktionsgrad zu erreichen scheinen mir doch relativ groß zu sein. Die Spezifikation ist ja auch so umfangreich, dass Implementierungen schon sehr unterscheidlich sein können.

Die Frage ist ja nicht OData ja oder nein, sondern Hypermedia ja oder nein, und wenn ja - welches?
OData konkurriert nicht mit Plain REST, sondern mit zB Siren.

Wie groß ein Aufwand ist, das kommt ja drauf an, wie groß die API ist.
Möchtest Du da jetzt Zeilen, Stunden, Punkte.. hören? Natürlich ist entsprechend jedem Contract ein erheblicher Aufwand dahinter.
Die Frage ist also viel eher: will ich diesen Aufwand und brauche ich Hypermedia?

In meinem alten Projekte haben wir eigenen eigenen Expression Parser geschrieben, der die Odoo API auf OData gebracht hat.
Hat eine (erfahrene) Person in zwei Wochen gemacht (der erste, gute Schuss).

OData findest Du vor allem im Microsoft Umfeld. So ziemlich jede neue WebAPI von Microsoft bietet eine OData Schnittstelle an (Azure, BI, Office 365...).
Facebook hatte es; aber durch die eigene Graph API ersetzt. http://www.odata.org/ecosystem/