OData con ServiceStack?

Editar

ServiceStack ahora ha agregado Auto Queryque es nuestro enfoque para habilitar servicios basados en datos que evita las trampas y los anti-patrones promovidos por OData.

ServiceStack soportará OData.

No.

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

Prácticas de desarrollo deficientes

OData es un pobre apto para ServiceStack que se opone vehementemente a las abstracciones pesadas y al "comportamiento mágico" que vemos como un ejemplo clásico de :

Cada minuto que guardas cuando tu marco de fantasía hace cosas mágicas para ayudarle a cabo los costos futuros-que diez minutos de depuración. No vale la pena.

No creemos que confiar en el comportamiento mágico de las manchas de caja negra dure la prueba del tiempo. Históricamente cada vez que hemos utilizado esto (por ejemplo, ADO.NET Conjuntos de datos, ASP.NET Dynamic Data) nos hemos encontrado rápidamente con las limitaciones inherentes a la flexibilidad de estos frameworks que son capaces de evolucionar para soportar nuevas prácticas de desarrolladores, paradigmas y tecnologías que no fueron diseñados para soportar, lo que resulta en ser rápidamente obsoletos a favor de nuevos frameworks que pueden. Este es un ciclo de reescritura que no queremos promover.

Promueve malas prácticas de servicio web

OData también promueve el anti-patrón en el que está exponiendo los detalles internos de implementación de su servicio acoplando estrechamente su contrato de servicio implícito a las tablas RDBMS subyacentes, lo que le brinda un control limitado sobre la capacidad de caché, re-factorización o capacidad de 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 en producción vinculados a ella, la estructura de las tablas se congela inhibiendo la capacidad de evolucionar sus tablas de BD existentes, ya que podrían romper los clientes existentes. La recomendación de ServiceStack es tener a sus clientes vinculados a una capa de servicio bien definida que usted es libre de re-factorizar la implementación.

En resumen, OData proporciona una funcionalidad rica, pero personalmente no recomiendo su uso fuera de la intranet donde no se controla y se puede implementar tanto el Cliente como el Servidor.

WebAPI es la mejor opción con soporte implícito para OData a través de returning la interfaz IQueryable<T>.

Solo se usa en tecnologías solo de Microsoft

Uno de los principales beneficios 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í solo ha sido adoptada esencialmente por Microsoft y iniciativas relacionadas con.NET.

OData es lento

OData se ha encontrado que es lento (que es contrario a nuestros objetivos centrales) y la falta de control sobre la implementación hace que sea difícil implementar limpiamente técnicas de mejora del rendimiento como el almacenamiento en caché sobre él.

Ejemplo concreto

He dado un ejemplo concreto en los comentarios de por qué OData es una mala idea, al final del IQueryable es Acoplamiento apretado post que voy a repetir aquí para la preservación:

Toda la idea de las interfaces de servicio web es exponer un API interoperable independiente de la tecnología para el mundo exterior.

Exponer un punto final IQueryable / OData acopla efectivamente su servicios para usar OData indefinidamente, ya que no podrá determinar a qué' espacio de consulta ' están vinculados los clientes existentes, es decir, a qué consultas existentes/tablas / vistas / propiedades que necesita congelar / soporte 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 la suya propia lógica personalizada en él, por ejemplo, Autorización, Almacenamiento en caché, Monitoreo, Limitación de tasas, etc. Y debido a que OData es muy lento, vas a golpear problemas de rendimiento / escalado con él temprano. La falta de control sobre el punto final, significa que efectivamente se dirige a una reescritura: https://coldie.net/?tag=servicestack

Vamos a ver qué tan factible sería moverse de un proveedor de OData implementación mirando una consulta existente de OData de Netflix api:

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

Este servicio está efectivamente acoplado a una Tabla / Vista llamada 'Titles' con una columna llamada 'Type'.

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

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

Ahora si por alguna razón necesita reemplazar la implementación de el servicio existente (por ejemplo, ha surgido una mejor plataforma tecnológica, se ejecuta demasiado lento y necesita mover este conjunto de datos a un NoSQL / Full-TextIndexing-backed sln) cuánto esfuerzo se necesitaría para reemplazar el OData impl (que está efectivamente enlazado a un esquema RDBMS y OData binary impl) a la consulta más intuitiva impl-agnóstica ¿abajo? No es imposible, pero como es prohibitivamente difícil implementar una API OData para una nueva tecnología, que reescribir + romper existente los clientes tienden a ser la opción preferida.

Dejar que las implementaciones internas dicten la url externa la estructura es una manera segura de romper los clientes existentes cuando las cosas necesitan cambio. Esta es la razón por la que debe exponer sus servicios detrás de Cool URIs, es decir, url permanentes lógicas (que no se ven obstaculizadas por la implementación) que no cambian, ya que generalmente no quiere limitar la opciones tecnológicas de sus servicios.

Podría ser una buena opción si quieres entregar adhoc ' exploratorio servicios ' en él, pero no es algo que nunca querría clientes externos atado a en un sistema de producción. Y si sólo voy a limitar su use a mi intranet local qué ventajas tiene sobre solo dar ¿una cadena de conexión de solo lectura? que permitirá a otros utilizar con su explorador Sql favorito, Informes o cualquier otra herramienta que hable SQL.

Actualización

Netflix acaba de retirar su catálogo OData, efectivo en 8 de abril de 2013 .

Se agregó una nueva respuesta en por qué recomendamos usar DTO limpios, bien definidos y no contaminados para definir cualquier servicio remoto con, 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 genéricas como OData son mucho más frágiles, complejas y difíciles de usar que las API basadas en intención equivalentes.