OData con ServiceStack?

Acabo de ver ServiceStack y estoy considerando construir un servicio con él.

¿Es posible servir feeds de OData con la stack de servicios para que yo pueda exponer IQueryable y consultarlo desde el cliente?

    Editar

    ServiceStack ahora ha agregado Auto Query, que es nuestro enfoque para habilitar servicios basados ​​en datos que evitan las trampas y antipatrones promovidos por OData .


    Will ServiceStack es compatible con OData.

    No.

    No directamente de todos modos. Si alguien ve algún valor en OData, puede agregar la funcionalidad necesaria como complemento opcional, pero nunca se integrará en el núcleo de ServiceStack.

    Pobres prácticas de desarrollo

    OData no encaja bien con ServiceStack, que se opone con vehemencia a las abstracciones pesadas y al “comportamiento mágico” que vemos como un ejemplo clásico de :

    Cada minuto que ahorras cuando tu lujoso marco hace cosas mágicas para ayudarte cuestan dinero en el futuro: diez minutos de depuración. No vale la pena.

    No creemos que depender del comportamiento mágico de los blobs de la caja negra alguna vez dure la prueba del tiempo. Históricamente, cada vez que hemos utilizado esto (por ejemplo, ADO.NET DataSets , ASP.NET Dynamic Data ) nos hemos topado rápidamente con las limitaciones intrínsecas y flexibles de estos frameworks que están en condiciones de evolucionar para admitir nuevas prácticas de desarrollo, paradigmas y tecnologías para las cuales no fueron diseñados para ser compatibles, lo que resulta en una rápida desaprobación a favor de marcos más nuevos que sí pueden. Este es un ciclo de reescritura que no deseamos promover.

    Promueve malas prácticas de servicio web

    OData también promueve el antipatrón en el que expone los detalles internos de implementación de su servicio, estrechando su contrato de servicio implícito con las tablas RDBMS subyacentes, lo que le brinda un control limitado sobre la capacidad de caché, refaccionamiento o versión de sus servicios en el futuro.

    Esto es similar a entregar su cadena de conexión de base de datos donde, tan pronto como tenga clientes vinculados a la producción, la estructura de las tablas se congelará, lo que inhibe la capacidad de desarrollar sus tablas de base de datos existentes ya que podría potencialmente romper los clientes existentes. La recomendación de ServiceStack consiste en hacer que sus clientes estén vinculados a una capa de servicios bien definida, de la que puede volver a factorizar la implementación.

    Para resumir, OData sí ofrece una gran funcionalidad, pero personalmente no recomiendo su uso fuera de la intranet, donde usted no controla, y puede implementar tanto el Cliente como el Servidor.

    WebApi es la mejor opción con soporte implícito para oData al devolver la interfaz IQueryable IQueryable .

    Solo se usa en las tecnologías exclusivas de Microsoft

    Una de las principales ventajas de los servicios web / remotos (y SOA en particular) es que proporciona una fachada independiente de la tecnología e interoperable sobre cualquier funcionalidad que desee exponer. Aunque OData es un estándar abierto, la tecnología en sí misma ha sido adoptada esencialmente solo por iniciativas relacionadas con Microsoft y .NET .

    OData es lento

    OData en sí mismo ha sido lento (lo que está en contradicción con nuestros objectives centrales) y la falta de control sobre la implementación dificulta la implementación limpia de técnicas de mejora del rendimiento como el almacenamiento en caché.

    Ejemplo concreto

    He dado un ejemplo concreto en los comentarios de por qué oData es una mala idea, al final de la publicación IQueryable es Tight Coupling, que repetiré aquí para preservación:

    La idea general de las interfaces de servicios web es exponer una API interoperable independiente de la tecnología al mundo exterior.

    La exposición de un punto final IQueryable / OData combina efectivamente sus servicios con el uso de OData indefinidamente ya que no podrá determinar de manera factible a qué “espacio de consulta” los clientes existentes están vinculados, es decir, qué consultas / tablas / vistas / propiedades existentes necesita congelar / soportar indefinidamente . Este es un problema al exponer cualquier implementación en el área de superficie de su API, ya que limita su capacidad para agregar su propia lógica personalizada, por ejemplo, Autorización, Almacenamiento en caché, Monitoreo, Límite de velocidad, etc. Y debido a que OData es realmente lento, alcanzará los problemas de rendimiento / escala con anticipación. La falta de control sobre el punto final significa que efectivamente se dirige a una reescritura: https://coldie.net/?tag=servicestack

    Veamos qué tan factible sería pasar de la implementación de un proveedor de datos a una consulta existente de la aplicación OData de Netflix:

    http://odata.netflix.com/Catalog/Titles ? $ filter = Escriba% 20eq% 20’Movie ‘% 20and% 20 (Rating% 20eq% 20’G’% 20or% 20Rating% 20eq% 20’PG-13 ‘)

    Este servicio ahora está efectivamente acoplado a una tabla / vista llamada ‘Títulos’ con una columna llamada ‘Tipo’.

    Y cómo se escribiría naturalmente si no estuvieras usando OData:

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

    Ahora, si por alguna razón necesita reemplazar la implementación del servicio existente (por ejemplo, ha surgido una mejor plataforma tecnológica, funciona demasiado lento y necesita mover este conjunto de datos a un sln respaldado por NoSQL / Full-TextIndexing) cuánto esfuerzo ¿Sería necesario reemplazar OData impl (que está efectivamente vinculado a un esquema RDBMS y Odata binary impl) a la consulta impl-agnostic más intuitiva a continuación? No es imposible, pero como es prohibitivamente difícil implementar una API OData para una nueva tecnología, esa reescritura + ruptura de clientes existentes sería la opción preferida.

    Permitir que las implementaciones internas dicten la estructura de URL externa es una manera segura de romper clientes existentes cuando las cosas tienen que cambiar. Esta es la razón por la que debe exponer sus servicios detrás de Cool URI, es decir, URL permanentes lógicas (que no están impedidas por la implementación) que no cambian, ya que generalmente no desea limitar las opciones de tecnología de sus servicios.

    Puede ser una buena opción si desea ofrecer “servicios exploratorios” adhoc, pero no es algo en lo que quiera que los clientes externos estén vinculados en un sistema de producción. Y si solo voy a limitar su uso a mi intranet local, ¿qué ventajas tiene el simple hecho de proporcionar una cadena de conexión de solo lectura? lo que permitirá que otros lo usen con su Sql Explorer, Reporting o cualquier otra herramienta que hable SQL.

    Actualizar

    Netflix acaba de retirar su catálogo OData, que entró en vigencia el 8 de abril de 2013 .

    Se agregó una nueva respuesta sobre por qué recomendamos utilizar DTO intactos, bien definidos y definidos para definir cualquier servicio remoto , que es una de las mejores prácticas de servicios remotos que el uso de OData no promueve.

    Buen artículo sobre por qué las API basadas genéricas como OData son mucho más frágiles, complejas y más difíciles de usar que las API equivalentes basadas en la intención .