Resumen de capas de conexión de datos y capas de presentación en una aplicación empresarial

Question

Estamos creando una aplicación empresarial en la que incorporaremos múltiples plataformas para las interfaces de usuario (es decir, la aplicación web ASP.net, la aplicación para Windows y, algún día, las aplicaciones móviles) y múltiples plataformas para las bases de datos de servicios de fondo (es decir, SQL Server, XML, Oráculo). Una necesidad adicional es que estas bases de datos de fondo estén centralizadas y se acceda a ellas a través de la web o localizadas en la computadora del cliente y ocasionalmente sincronizadas con el servidor central.

¿Alguien puede dar consejos sobre cómo podemos abstraer la capa de interfaz de usuario & amp; ¿La capa de datos para que podamos crear más fácilmente la adaptabilidad plug-and-play entre las distintas interfaces de usuario y las distintas opciones para los DB? Por ejemplo: en un caso, podemos tener una aplicación web ejecutándose en un servidor centralizado a través de Internet, y podemos tener máquinas remotas ejecutando copias localizadas a través de una aplicación de Windows. A intervalos programados, queremos que todas las máquinas estén sincronizadas para que todas puedan tener datos casi en tiempo real.

También necesitamos asesoramiento sobre el manejo de las diversas cadenas de conexión involucradas para que la única configuración que deba cambiarse en cualquier aplicación sea "local". o " remoto " ;, que luego determinaría la cadena de conexión necesaria.

Answer 1

Resumir la capa de presentación es un concepto bastante fácil una vez que dominas la arquitectura de n niveles. Solo enfócate en diferenciar " lógica de dominio " de " lógica de aplicación " ;. La lógica de dominio es común en sus diferentes plataformas, y la lógica de la aplicación es específica de la plataforma. Por ejemplo, la validación de datos es lógica de dominio (aunque es bueno cuando puedes hacerlo en el front-end, lo que hace las cosas más complejas, pero trabaja conmigo aquí ...) y decidir a qué URL redirigir después de alguna acción es la aplicación lógica. Asegúrese de poner la lógica de su dominio a un nivel que pueda ser utilizado por cualquier plataforma, y ??asegúrese de no colocar ninguna lógica de aplicación en la capa de su dominio.

La otra mitad de tu pregunta parece ser tu enfoque más amplio, pero quisiera pedir una aclaración aquí, ya que puedo discernir dos preguntas esenciales diferentes.

1. Espero que no vayas por el "santo grial" de independencia de la base de datos. Este es siempre un objetivo elevado durante la fase de diseño, que casi siempre, casi siempre, no es necesario.

   Si eso no es lo que está buscando, le sugiero que sepa qué objetos están almacenados en qué medio de persistencia, y que evite la complejidad de la flexibilidad y simplemente codifique sus rutas verticales como rectas. reenviar una manera como sea posible. IE no codifica material adicional en alguna clase de negocio que almacena sus datos en Oracle para permitirle colocarlo en SQL Server "en algún momento en el futuro". (Regresé a la independencia de la base de datos, ¿no?)

2. La cuestión del almacenamiento en caché de datos localmente para mejorar el rendimiento de ciertas plataformas es específica de esas plataformas y le sugiero que consulte los Clientes inteligentes y el marco / orientación de almacenamiento en caché que tiene el equipo de MS P & amp; P. He trabajado bastante exclusivamente en material web durante los últimos dos años, pero en 05/06 fue bastante bueno, y mientras tanto han estado trabajando mucho en sus cosas de Smart Client.

Answer 2

Consideraría el uso del modelo de proveedor para establecer las conexiones de base de datos en su aplicación.

Comenzaría mirando los ejemplos y detalles proporcionados en el Bloque de aplicaciones de datos de Microsoft, creo que te ayudará a lograr parte del camino.