Argumentos del uso de WCF/OData como capa de acceso en lugar de EF/L2S/nHibernate directamente

Question

Desarrollamos aplicaciones web principalmente de poco tráfico pero altamente especializadas. Normalmente usamos L2S, EF o nHibernate como capa de acceso y luego le arrojamos Asp.Net MVC y en el cual para las operaciones crud normales consultamos ISession/DataContext directamente, pero para funciones/efectos secundarios más avanzados lo colocamos en algún tipo de capa de servicio.

Ahora, se me ocurrió publicar los datos a través de OData (WCF Data Service) y consultarlos desde los controladores (o incluso desde jQuery cuando aparece el motor de una buena plantilla) y publicar las operaciones de servicio a través de un servicio WCF (o como métodos personalizados en el Servicio de datos WCF?). ¿Qué ventajas/desventajas presenta esta arquitectura?

¿Obtengo algo, excepto una mayor complejidad y latencia? Mejores separaciones de preocupaciones (¿o es solo una ilusión)?

Editar: ¿Puede ser una buena idea crear una solución completa impulsada por ajax con, por ejemplo. WCF RIA Services? ¿O uno pierde demasiada flexibilidad? Siente que puede despachar completamente sus puntos de vista desde su lógica, entonces, demonios, uno debería ser capaz de simplemente escribir HTML puro, ¿ni siquiera debería necesitarse un MVC asp.net? pero supongo que surgen muchos problemas nuevos?

Answer 1

Como menciona TomTom, no es necesario pagar el costo del bucle invertido para OData cuando se está dentro de un proceso. Si tiene línea de vista directa a su base de datos y es la base de datos de su propia aplicación, entonces no hay razón para poner los Servicios de datos de WCF en el medio. Continuaría usando una de las otras opciones que mencionaste (L2S, EF, nHibernate).

Ahora, si necesita exponer datos sobre su punto final http para que otras aplicaciones lo consuman, o incluso para su propia aplicación si tiene algún código jQuery en el cliente que necesita acceder a los datos del servidor, entonces definitivamente un OData El punto final puede ayudar y WCF Data Services es la forma más sencilla de crear uno.

Answer 2

Do not Do it. Lo siento, pero este es un enfoque estúpido sobre ingeniería. Estás en UN PROCESO e insistes en ejecutar una conexión de red Y codificar todos los datos que pasan en XML y volver atrás, además de ejecutarlo a través de una conexión HTTP con semántica de consulta limitada. No le digas a nadie que incluso lo intentaste.

La separación de la preocupación es una ilusión aquí: reemplaza un modelo de dominio altamente optimizado con una capa de datos simplificada.

QUE DIJO: Me encanta OData - genial. Pero no es una tecnología dentro del programa, es una tecnología FRONT END, como ASP.NET MVC, simplemente no para el usuario final, sino para que OTRO programa se integre en sus datos. Se debe usar en escenarios similares y al exponer datos a través de bordes de confianza (Silverlight, por ejemplo, es un límite de confianza ya que las solicitudes pueden ser falsificadas).

NO está optimizado para reemplazar en proceso capas de tiempo de ejecución de aplicaciones de gama alta como NHibernate.

Answer 3

Para ser justos, hay ventajas en este enfoque que pueden superar las preocupaciones sobre el rendimiento, que sin duda son tremendos. Una aplicación construida de esta manera tendrá una latencia de orden de magnitud mayor y puede costar varias veces más en recursos de cómputo para ejecutarse que una solución en proceso.

Dicho esto, en escenarios de desarrollo donde los recursos humanos son limitados, esto puede funcionar mejor. Permite que los contratistas sean contratados rápidamente para escribir nuevas pantallas o aplicaciones completamente nuevas muy rápidamente en el idioma que les resulte más conveniente. Los desarrolladores pueden ponerse al día más rápido que una solución propia de propiedad.No más contraseñas sa en archivos de configuración, inyección de una capa de seguridad personalizada si es necesario, registro unificado y auditoría, combinando varios almacenes de datos en un solo recurso. Si tiene una plataforma heterogénea, no necesita escribir SDK, ya se han escrito en muchos idiomas importantes. oData funciona muy bien con MS Excel, que es una gran victoria en muchas organizaciones. Dependiendo de la topología de su red, puede ser más barato e incluso más rápido enrutar a través de Internet que utilizar una línea arrendada si se encuentra en una oficina remota o detrás de un firewall (en un sitio de cliente que hace una demostración, por ejemplo) .

Para grandes conjuntos de datos, la sobrecarga de la solicitud y el embalaje se vuelve menos importante. Para escenarios de informes, por ejemplo. Si bien nunca diseñé algo como esto, puedo ver dónde podría ser útil, dependiendo de su cultura corporativa y recursos disponibles, consumir endpoints oData internamente.

Answer 4

WCF Data Services y OData admiten JSON, por lo que puede minimizar la carga aprovechando eso. Además, con WCF Data Services puede controlar completamente su acceso a los datos. No tiene que enrollar Entity Framework. Puedes personalizar todo. El beneficio es que la estructura del protocolo se maneja completamente para usted mediante el uso de WCF Data Services y OData. Y consumir el servicio de MVC es agregar una referencia de servicio. WCF Data Services se ejecuta en WCF, por lo que tiene la capacidad de realizar otros servicios web además de la entrega de tipo OData, por lo que es extremadamente flexible.

Existen limitaciones aquí y allá que vienen con la naturaleza de OData, así como con la forma en que WCF Data Services maneja OData, pero son bastante específicas y si surgen en su arquitectura hay formas de evitarlas.

Si su solución está aislada de una sola aplicación web, entonces tener la capa de datos integrada en esa aplicación funciona bien. Pero si tiene alguna necesidad de que otra aplicación o proceso llegue a la capa de datos o la lógica de negocios compartida, entonces explorar la opción de poner su capa de datos en un Servicio de Datos WCF bien vale la pena. Por ejemplo, podría escribir un script de PowerShell para llamar a un método de servicio web en 2 líneas de código. Por lo tanto, si tiene una lógica de dominio que desea ejecutar desde su aplicación web y desde una línea de comando o una tarea programada, su capa WCF Data Service podría manejar ese escenario para todos sin tener que duplicar la lógica o el código.

Muchas formas de pelar un gato. He utilizado ambos enfoques en aplicaciones comerciales y no diría que uno u otro deberían evitarse. Ambos funcionan bien y proporcionan un gran valor sin ser perjudicial.

Answer 5

TomTom tiene muchos votos y, aunque no está equivocado, tampoco tiene razón, a pesar de su tono persuasivo.

En este caso particular, el OP parece escribir una aplicación de estilo LOB de intranet que probablemente solo se vea obstaculizada por un servicio OData que imite la base de datos subyacente, pero ¿y si no imitara la base de datos subyacente?

Si estaba construyendo una aplicación basada en fuentes de datos futuros diversos o desconocidos, la capa de servicios puede unificar, volver a presentar, simplificar y agregar esos servicios, incluso si una gran proporción de consultas finalmente regresa a un servidor SQL en la habitación contigua

Del mismo modo, si está construyendo una aplicación de escala masiva, y por escala quiero decir millones de usuarios que esperan esperar unos segundos entre acciones, no millones de operaciones FX por hora, y luego colocar una capa de servicios entre su aplicación los datos son un patrón común. La escalabilidad de Internet se basa en muchos pequeños servidores HTTP sin estado y en la infraestructura de caché intermedia.

En la vida real, las mismas consultas se ejecutan innumerables veces, las personas actualizan las páginas o hacen clic en el mismo enlace una y otra vez. Nadie realmente pide 10m filas, porque no muchos humanos pueden verlo de una vez.Así que trabajar en páginas pequeñas mantiene el flujo de datos y solicita el intercalado. También tiene la oportunidad de introducir un caché RAM compartido en la capa de servicios, o incluso una base de datos RAM.

Incluso puede encontrar que necesita fragmentar su base de datos o particionarla entre SQL y un almacén de claves/valores. A continuación, puede hacer las uniones en el nivel medio, escalar y descargar el material de unión y de cálculo intensivo lejos del servidor de la base de datos.

La regla con escala de Internet es que la base de datos es su punto de acceso y usted debe hacer todo lo posible para evitar que cualquiera le hable. Sea ese caché HTTP local en un iPad, en el proxy de su ISP, en el caché de salida IIS, o en un caché Redis, todas esas capas ayudan a repartir la carga, a aliviar la carga.

Así que si Carl vino a entrevistarme y me dijo que había considerado poner una capa OData antes de sus cuadros SQL, me interesaría escuchar su razonamiento.