OData avec ServiceStack?

J'ai juste vu ServiceStack et j'envisage la construction d'un service avec elle.

Est-il possible de servir des flux OData avec le service de la pile, de sorte que je serais en mesure d'exposer IQueryable et de requête à partir de la client?

  • Je n'ai aucune expérience avec ServiceStack, mais je sais que les Services de Données WCF a plein OData soutien, et ASP.NET Web API prend en charge les paramètres si vous retournez IQueryable. voir msdn.microsoft.com/en-us/library/cc668788.aspx
  • WebAPI est parfait, le seul problème est que je n'aurai pas un client-code généré pour moi si je l'utilise.. je vais regarder de plus près les Services de Données WCF s'ils pouvaient m'aider. Merci pour les commentaires!
InformationsquelleAutor Shaddix | 2012-03-06
  1. 83

    Modifier

    ServiceStack a maintenant ajouté Auto Requête qui est de notre approche à l'activation de la data-driven services qui évite les pièges et les anti-modèles promus par OData.

    Sera ServiceStack en charge OData.

    Pas.

    Pas directement en tout cas. Si quelqu'un voit aucune valeur en OData, ils sont libres d'ajouter de la fonctionnalité en option Plugin - mais il ne sera jamais construit dans le ServiceStack de base.

    Mauvaises pratiques de développement

    OData est un mauvais ajustement pour ServiceStack qui s'oppose avec véhémence lourd abstractions et "la magie de comportement", qui nous considérons comme une un exemple classique de la:

    Chaque minute vous enregistrer lors de votre fantaisie cadre magique des choses à
    vous aider coûts futurs-vous dix minutes de débogage. Pas la peine.

    Nous ne pensons pas que de compter sur la magie comportement de "boîte noire", les blobs ne dure jamais à l'épreuve du temps. Historiquement, chaque fois que nous avons utilisé (par exemple, à ADO.NET ensembles de données, ASP.NET Dynamique de Données) nous avons rapidement courir dans la inhérents à-flexible limites de ces cadres qui sont en mesure d'évoluer pour soutenir les nouveaux développeur pratiques, les paradigmes et les technologies qu'ils n'ont pas été conçus à l'appui, entraînant rapidement dépréciée en faveur de nouveaux cadres de qui peut. C'est une ré-écriture du cycle nous n'avons pas veut promouvoir.

    Favorise mauvais service web pratiques

    OData favorise également l'anti-modèle où vous êtes d'exposer la mise en œuvre interne de détails de votre service étroitement associant implicitement votre contrat de service aux sous-jacent SGBDR tables vous donnant un contrôle limité sur la possibilité de mise en cache, re-factoring ou à la version de la capacité de vos services dans l'avenir.

    Ceci est similaire à la remise de votre db chaîne de connexion où dès que vous avez des clients dans la production de liaison, la structure des tables de gel, en inhibant la capacité de faire évoluer votre base de données existante tables, car il pourrait briser les clients existants. ServiceStack de la recommandation est d'avoir vos clients lié à une couche de service que vous êtes libre de re-facteur de la mise en œuvre de l'.

    Pour résumer OData est en effet riche en fonctionnalités, mais personnellement, je ne recommande pas son utilisation en dehors de l'intranet où vous ne contrôlez pas et peut déployer à la fois Client et Serveur.

    WebApi est la meilleure option avec le soutien implicite de oData par le retour de la IQueryable<T> interface.

    Seulement utilisé dans Microsoft seulement les technologies

    L'un des principaux avantages du web/remote services (SOA) est qu'il fournit une technologie de diagnostic et interopérables façade de plus de toutes les fonctionnalités que vous souhaitez exposer. Bien que OData est un standard ouvert, la technologie elle-même est essentiellement seulement été adoptée par Microsoft et .NET initiatives liées à la.

    OData est lent

    OData lui-même s'est trouvé être lent (ce qui est contre nos objectifs de base) et le manque de contrôle sur la mise en œuvre rend difficile à proprement mettre en œuvre l'amélioration de la performance des techniques comme la mise en cache sur elle.

    Exemple concret

    Je vous ai donné un exemple concret, dans les commentaires pourquoi oData est une mauvaise idée, à la fin de la IQueryable est le Couplage post qui, je le répète ici pour la préservation:

    L'idée d'interfaces de service web est d'exposer une
    technologie-agnostique interopérables API pour le monde extérieur.

    D'exposer un IQueryable/OData extrémité efficacement les couples de votre
    services à l'aide de OData indéfiniment tant que vous ne serez pas en mesure de procéder à la
    déterminer ce que les "requête" espace clients existants sont liées, par exemple, ce
    les requêtes existantes/tables/vues/propriétés que vous avez besoin de gel/support
    indéfiniment. C'est un problème quand on expose une mise en œuvre de la
    la surface de votre API, car il limite votre capacité à ajouter votre propre
    la logique personnalisée sur elle, par exemple, l'Autorisation, la mise en Cache, la Surveillance,
    De Limitation de vitesse, etc. Et parce que OData est vraiment lent, vous serez frappé de
    performance/de mise à l'échelle des problèmes avec elle au début. Le manque de contrôle sur
    le point de terminaison, signifie que vous êtes effectivement en route pour une réécriture:
    https://coldie.net/?tag=servicestack

    Permet de voir dans quelle mesure serait de s'éloigner d'un fournisseur oData
    mise en œuvre par la recherche lors d'une requête existante à partir de Netflix, est OData
    api:

    http://odata.netflix.com/Catalog/Titles?$filtre=Type%20eq%20'Movie'%20and%20(Taux%20eq%20'G'%20or%20Rating%20eq%20'PG-13')

    Ce service est effectivement couplé à une Table/Vue
    "Titres" avec une colonne appelée "Type".

    Et comment il serait naturellement écrit si vous n'étiez pas à l'aide de OData:

    http://api.netflix.com/movies?ratings=G PG-13

    Maintenant, si pour quelque raison que ce soit vous avez besoin pour remplacer la mise en œuvre de
    le service existant (par exemple, une meilleure plate-forme de technologie a vu le jour,
    il fonctionne trop lent et vous avez besoin de déplacer cet ensemble de données sur un
    NoSQL/Plein-TextIndexing adossés à la sln) combien d'effort aurait-il prendre pour
    remplacer le OData impl (qui est effectivement lié à un SGBDR schéma
    et OData binaire impl) à la plus intuitive impl-agnostique requête
    ci-dessous? Il n'est pas impossible, mais comme il est extrêmement difficile de
    mettre en œuvre un OData API pour une nouvelle technologie, que la réécriture de + de rupture
    les clients existants ont tendance à être l'option préférée.

    Laisser interne implémentations de dicter la face externe de l'url
    la structure est un moyen sûr de rompre les clients existants quand les choses doivent
    changement. C'est pourquoi vous devez exposer vos services derrière Cool URIs,
    c'est à dire logique permanente de l'url (qui sont entravées par la mise en œuvre)
    qui ne change pas, comme vous, en général, ne veulent pas limiter l'
    les choix de la technologie de vos services.

    Il pourrait être une bonne option si vous souhaitez vous faire livrer adhoc exploratoires
    services sur elle, mais ce n'est pas quelque chose que je n'avais jamais envie de clients externes
    reliée à un système de production. Et si je ne vais à la limite de ses
    utiliser pour mon intranet local quels avantages a-t-elle plus juste de donner
    une connexion en lecture seule chaîne de caractères? ce qui permettra à d'autres de les utiliser avec
    leur favori Sql Explorer, de Déclaration ou tout autre outils qui parle
    SQL.

    Mise à jour

    Netflix vient de à la retraite de son OData catalogue, efficace sur avril 8, 2013.

    Ajouté une nouvelle réponse sur pourquoi nous recommandons l'utilisation propre, bien défini intacte DTO pour définir tous les services à distance avec, qui est à distance de services de meilleures pratiques à l'aide de OData ne pas faire la promotion.

    Bon article sur pourquoi générique en fonction Api comme OData sont beaucoup plus fragile, complexe et plus difficile à utiliser que l'équivalent d'intention basé sur les Api.

    • Tous les bons points, mais garder à l'esprit pour beaucoup de "l'entreprise" les solutions de tous les clients peuvent faire partie d'un étroitement associée distribués au système, auquel cas OData peut encore être une approche viable.
    • En fait je me sens comme cette réponse débordait du OData standard avec implémentations. Le implemenations sont ce qui donne de la magie et de l'exposer implemation de détails. OData lui-même ne dit pas le modèle de données doit être de db schéma, il arrive, la plupart des implémentations de soutenir une telle chose hors de la boîte.
    • Comme pour "utilisé Uniquement dans Microsoft uniquement technologies", dès 2016, il semble OData peut obtenir la traction comme on le voit par son absorption par les SAP, IBM, Oracle, SalesForce, TIBCO etc. (non pas que ces noms sont nécessairement associés à la technologie innovante des adoptions!)
    • AutoQuery n'a pas l'air très cool, mais il ne semble pas soutenir insert/update/delete qui ne OData
    InformationsquelleAutor mythz