c# - dell - servicestack ormlite

OData con ServiceStack?

Question

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

¿Es posible servir feeds OData con la pila de servicios para poder exponer IQueryable y consultarlos desde el cliente?

Answer 1

Editar

ServiceStack ahora ha agregado Auto Query, que es nuestro enfoque para habilitar servicios controlados por datos que eviten las trampas y los patrones que promueve 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 Plugin opcional, pero nunca se integrará en el núcleo de ServiceStack.

Malas prácticas de desarrollo

OData no es una buena opción para ServiceStack que se opone vehementemente a las abstracciones pesadas y al "comportamiento mágico" que consideramos como un ejemplo clásico de :

Cada minuto que ahorra cuando su marco de lujo hace cosas mágicas para ayudarlo a salir adelante le cuesta diez minutos de depuración. No vale la pena.

No creemos que confiar en el comportamiento mágico de las burbujas de la caja negra haya durado la prueba del tiempo. Históricamente, cada vez que usamos esto (por ejemplo, ADO.NET DataSets , ASP.NET Dynamic Data ) nos encontramos rápidamente con las limitaciones inherentes de la flexibilidad de estos marcos, que son capaces de evolucionar para admitir nuevas prácticas de desarrollador, paradigmas y tecnologías para las que no fueron diseñadas para ser compatibles, lo que se traduce en una rápida desaprobación en favor de marcos más nuevos que 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 está exponiendo los detalles de implementación interna de su servicio, uniendo su contrato de servicio implícito a las tablas RDBMS subyacentes, lo que le otorga un control limitado sobre la capacidad de almacenamiento en caché, re-factorización o versión de sus servicios en el futuro.

Esto es similar a la entrega de su cadena de conexión db donde, tan pronto como tenga clientes en producción vinculados a ella, la estructura de las tablas se congelará impidiendo la evolución de sus tablas de base de datos existentes, ya que podría romper los clientes existentes. La recomendación de ServiceStack es que sus clientes estén vinculados a una capa de servicio bien definida de la cual usted puede redimensionar la implementación.

Para resumir, OData proporciona una funcionalidad rica, pero personalmente no recomiendo su uso fuera de la intranet donde no controla y puede implementar el Cliente y el Servidor.

WebApi es la mejor opción con soporte implícito para oData a través de la devolución de la interfaz IQueryable IQueryable<T> .

Solo se usa en tecnologías de Microsoft

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

OData es lento

La propia OData ha resultado ser lenta (lo cual es contrario a nuestros objetivos 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é sobre ella.

Ejemplo concreto

He dado un ejemplo concreto en los comentarios de por qué oData es una mala idea, al final de IQueryable está el post de Acoplamiento hermético, que repetiré aquí para preservar:

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

Exponer 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é clientes de "espacio de consulta" están vinculados los clientes existentes, es decir, qué consultas / tablas / vistas / propiedades existentes necesita para congelar / apoyar 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, Limitación de velocidad, etc. Y debido a que OData es muy lenta. Tendrá problemas de rendimiento / escalamiento temprano. La falta de control sobre el punto final significa que efectivamente va a reescribir: https://coldie.net/?tag=servicestack

Veamos qué tan factible sería abandonar la implementación de un proveedor de datos al ver una consulta existente desde la API de OData de Netflix:

http://odata.netflix.com/Catalog/Titles ? $ filter = Tipo% 20eq% 20''Movie ''% 20and% 20 (Clasificación% 20eq% 20''G''% 20or% 20Evaluación% 20eq% 20''PG-13 '')

Este servicio está efectivamente acoplado ahora 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, se ejecuta demasiado lento y necesita mover este conjunto de datos a una sln con respaldo NoSQL / Full-TextIndexing) cuánto esfuerzo ¿Se necesitaría reemplazar la implementación de OData (que se enlaza efectivamente con un esquema RDBMS y una implementación binaria de OData) por la consulta más intuitiva de no agnóstico a continuación? No es imposible, pero como es prohibitivamente difícil implementar una API OData para una nueva tecnología, la opción de reescritura + ruptura de clientes existentes podría ser la opción preferida.

Dejar que las implementaciones internas dicten la estructura externa de la URL es una forma segura de romper los clientes existentes cuando las cosas deben cambiar. Esta es la razón por la que debería exponer sus servicios detrás de Cool URIs, es decir, URL permanentes permanentes (que no están limitadas por la implementación) que no cambian, ya que generalmente no desea limitar las opciones tecnológicas de sus servicios.

Podría ser una buena opción si desea ofrecer ''servicios exploratorios'' ad hoc, pero no es algo a lo que me gustaría que los clientes externos se unan en un sistema de producción. Y si solo voy a limitar su uso a mi intranet local, ¿qué ventajas tiene sobre el solo hecho de proporcionar una cadena de conexión de solo lectura? que permitirá a otros utilizar con su explorador de SQL favorito, informes 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 el uso de DTO no contaminados, limpios y bien definidos para la definición de cualquier servicio remoto , lo cual 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 en genéricos como OData son mucho más frágiles, complejas y difíciles de usar que las API equivalentes basadas en intenciones .