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
ImageTools for Silverlight: http://imagetools.codeplex.com | http://www.silverdiagram.net | http://www.cleancodedeveloper.de b:::
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
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
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?
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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.
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.
ImageTools for Silverlight: http://imagetools.codeplex.com | http://www.silverdiagram.net | http://www.cleancodedeveloper.de b:::
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/
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code