Desde hace un tiempo, mi equipo y yo hemos envuelto nuestra capa de acceso a datos en una fachada de servicio web (utilizando WCF) y llamándola desde la capa de lógica de negocios . Mientras tanto, podríamos simplemente usar el patrón de repositorio donde la capa de lógica de negocios consume la capa de acceso a datos localmente a través de una interfaz, y en cualquier momento, podemos cambiar las cosas para que lleguen a un servicio (si es necesario).Para envolver o no: ajustar el acceso a datos en una fachada de servicio
La pregunta es: ¿Cuándo es un buen momento para envolver la capa de acceso a datos en una fachada de servicio y cuándo no? En este momento, parece que la principal ventaja es que otras aplicaciones pueden consumir el servicio, pero si son aplicaciones internas escritas en .NET, pueden consumir el ensamblado .NET en su lugar. ¿Hay otras ventajas de tener el DAL envuelto en un servicio que desconozco?
Incluso para una aplicación interna, consumir directamente el conjunto .NET podría ser un PITA para actualizar si tiene muchos usuarios de su ensamblado, pero un servicio web sería mucho más flexible. – Nate
Esta es una gran pregunta ... El gasto relacionado con la serialización/transporte/deserialización puede ser realmente costoso, por lo que tiene sentido considerar otros modelos. Por otro lado, tener una fachada de servicios puede hacer que sea más fácil enriquecer y transformar datos. Otro aspecto agradable de este patrón es la capacidad de integrar puntos finales en cola para evitar el almacenamiento. – JoeGeeky