asp.net-mvc - net - update model from database entity framework
Argumentos del uso de WCF/OData como capa de acceso en lugar de EF/L2S/nHibernar directamente (5)
Desarrollamos principalmente aplicaciones web de poco tráfico pero altamente especializadas. Normalmente usamos L2S, EF o nHibernate como capa de acceso y luego le lanzamos Asp.Net MVC, y en las operaciones crudas normales consultamos el ISession / DataContext directamente, pero para funciones / efectos secundarios más avanzados lo ponemos en algún tipo de capa de servicio.
Ahora, pensé en publicar los datos a través de OData (servicio de datos WCF) y consultarlos desde los controladores (o incluso desde jQuery cuando aparezca un buen motor de plantillas) y publicar las operaciones del servicio a través de un servicio WCF (o como métodos personalizados). en el servicio de datos WCF?). ¿Qué ventajas / desventajas plantea esta arquitectura?
¿Gano algo excepto una mayor complejidad y latencia? ¿Mejores separaciones de preocupaciones (o es solo una ilusión)?
Edición: ¿Puede ser una buena idea crear una solución completa basada en ajax con, por ejemplo, ¿WCF RIA Services ? ¿O uno pierde demasiada flexibilidad? Se siente como si pudieras despachar completamente tus vistas desde tu lógica entonces, diablos, uno debería ser capaz de escribir solo HTML puro, ¿ni siquiera se necesita un MVC de asp.net? ¿Pero supongo que están surgiendo muchos problemas nuevos?
Como lo menciona TomTom, no desea pagar el costo del bucle de retorno para OData 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 WCF Data Services en el medio. Continuaría usando una de las otras opciones que mencionó (L2S, EF, nHibernate).
Ahora, si necesita exponer los datos a través de su punto final http para que otras aplicaciones los consuman, o incluso para su propia aplicación si tiene algún código jQuery en el cliente que necesita acceder a los datos desde el servidor, entonces definitivamente un punto final OData puede ayudar y WCF Data Services es la forma más sencilla de crear uno.
No lo hagas Lo siento, pero este es un enfoque estúpido sobre-diseñado. ¿Está EN UN PROCESO e insiste en ejecutar una conexión de red Y codificar todos los datos que pasan a XML y volver a ejecutarlos, además de ejecutarlos 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 integrada en el 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 cuando se exponen datos a través de bordes de confianza (Silverlight, por ejemplo, es un borde de confianza, ya que las solicitudes se pueden falsificar).
NO está optimizado para reemplazar las capas de tiempo de ejecución de aplicaciones de alto nivel de proceso como NHibernate.
Para ser justos, este enfoque tiene beneficios que pueden superar los problemas de rendimiento, que ciertamente son tremendos. Una aplicación construida de esta manera tendrá órdenes de magnitud más latencia y puede costar varias veces más recursos de cómputo para ejecutar que una solución en proceso.
Dicho esto, en escenarios de desarrollo donde los recursos humanos son limitados, esto puede funcionar mejor. Permite a los contratistas ser contratados rápidamente para escribir nuevas pantallas o aplicaciones completamente nuevas muy rápidamente en el idioma que más les convenga. Los desarrolladores pueden ponerse al día más rápido que una solución patentada propia. No más contraseñas en los archivos de configuración, inyección de una capa de seguridad personalizada si es necesario, registro y auditoría unificados, combinando varios almacenes de datos en un recurso consistente. Si tiene una plataforma heterogénea, no necesita escribir SDK, ya que se han escrito en muchos idiomas importantes. oData funciona muy bien con MS Excel, que es una gran victoria para muchas organizaciones. Dependiendo de la topología de su red, puede ser más barato e incluso más rápido enrutarse a través de Internet que usar una línea alquilada si se encuentra en una oficina remota o detrás de un firewall (en un sitio de un cliente que realiza una demostración, por ejemplo) .
Para grandes conjuntos de datos, la sobrecarga de la solicitud y el empaquetado se vuelve menos importante. Para escenarios de informes, por ejemplo. Si bien nunca he diseñado algo como esto, puedo ver dónde puede ser útil, dependiendo de su cultura corporativa y los recursos disponibles, para consumir los puntos finales de oData internamente.
TomTom tiene muchos votos y, aunque no está equivocado, tampoco lo está, a pesar de su tono persuasivo.
En este caso en particular, el OP parece estar escribiendo una aplicación de estilo LOB de intranet que probablemente solo se vea obstaculizada por un servicio OData que imita la base de datos subyacente, pero ¿y si él no imitara la base de datos subyacente?
Si estuviera creando una aplicación basada en varias o futuras fuentes de datos desconocidas, entonces la capa de servicios puede unificar, volver a presentar, simplificar y agregar esos servicios, incluso si una gran parte de las consultas finalmente regresan a un servidor SQL en la siguiente sala.
De manera similar, si está creando una aplicación de escala masiva, y por escala me refiero a millones de usuarios que esperan esperar unos segundos entre acciones, no millones de operaciones de divisas por hora, y luego colocar una capa de servicios entre su aplicación, los datos son una patrón común. La escalabilidad de Internet se basa en muchos servidores HTTP pequeños sin estado y en la infraestructura de almacenamiento en caché en el medio.
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 filas de 10 m, porque no muchos humanos pueden verlo de una sola vez. Por lo tanto, trabajar en páginas pequeñas mantiene el flujo de datos y solicita el intercalado. También tiene la oportunidad de introducir un caché de RAM compartido en la capa de servicios, o incluso una base de datos de RAM.
Incluso puede encontrar que necesita dividir su base de datos o particionarla entre SQL y un almacén de clave / valor. Luego, puede realizar las uniones en el nivel medio, ampliarlas y descargar las cosas de unión y de uso intensivo de cómputo fuera del servidor de la base de datos.
La regla con la escala de Internet es que la base de datos es su punto de acceso y usted debe hacer todo lo posible para evitar que alguien hable con ella. Ya sea que la caché HTTP local en un iPad, en el proxy de su ISP, en la caché de salida de IIS o en la caché de Redis, todas esas capas están ayudando a distribuir la carga, alivian la carga.
Entonces, si Carl vino a entrevistarme y me dijo que había considerado poner una capa OData antes de sus casillas SQL, me interesaría escuchar su razonamiento.
WCF Data Services y OData son compatibles con JSON, por lo que puede minimizar la carga útil aprovechando eso. Además, con los servicios de datos de WCF puede controlar completamente su acceso a los datos. No tienes que rodar Entity Framework. Puedes personalizar todo. El beneficio es que la estructura del protocolo se maneja por completo mediante WCF Data Services y OData. Y consumir el servicio de MVC es una Referencia de Servicio Agregar. WCF Data Services se ejecuta en WCF, por lo que tiene la capacidad de hacer otros servicios web más allá de la simple entrega de tipo OData, por lo que es extremadamente flexible.
Hay limitaciones aquí y allá que vienen con la naturaleza de OData, así como la forma en que WCF Data Services maneja OData, pero son bastante específicas y si surgen en su arquitectura, existen formas de evitarlas.
Si su solución está aislada en una sola aplicación web, entonces tener la capa de datos incrustada 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 a la lógica empresarial compartida, entonces vale la pena explorar la opción de colocar su capa de datos en un servicio de datos de WCF. 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. Entonces, si tiene lógica de dominio que desea poder ejecutar desde su aplicación web y desde una línea de comandos o una tarea programada, entonces su capa de servicio de datos WCF podría manejar ese escenario para todos sin tener que duplicar la lógica o el código.
Muchas formas de despellejar a un gato. He utilizado ambos enfoques en aplicaciones de negocios y no diría que uno u otro debe evitarse. Ambos funcionan bien y proporcionan mucho valor sin ser perjudiciales.