Necesita asesoramiento sobre soluciones en capas, separación de preocupaciones, etc.

Question

Tenemos una aplicación en capas, o al menos está en el proceso de transición a una, desglosada de la siguiente manera:

• Interfaz (interfaz de usuario o interfaz de aplicación, es decir, servicio web, etc.)
• Lógica empresarial
• Acceso a datos

Para hacer el resto de esta pregunta más concreta, describiré una instancia específica.

Tenemos una interfaz de usuario, que tiene un objeto controlador detrás (la capa de lógica de negocios). Este controlador se comunica con la base de datos a través de otro objeto (la capa de acceso a datos).

En un contexto dado, la interfaz de usuario permite al usuario elegir un empleado para vincular la operación que se está realizando. Dado que hay reglas con respecto a qué empleados puede elegir el usuario (bueno, cualquier mundo fuera del controlador realmente), el controlador proporciona dos cosas para esto:

• una propiedad legible que contiene una lista de empleados disponibles para elegir
• una propiedad de lectura / escritura que contiene el empleado elegido actualmente

La interfaz de usuario puede leer la lista y usarla para completar un cuadro combinado.

En la versión 1 de esta aplicación, el cuadro combinado contiene el número de identificación del empleado + el nombre del empleado.

Todo está bien ...

... hasta la versión 1.1, una corrección de errores. Un usuario se queja de que no puede elegir entre Jimmy Olson y Jimmy Olson porque la aplicación no le facilita lo suficiente como para saber cuál es cuál. Sabe que hay un Jimmy en el departamento de ventas y otro en el departamento de desarrollo, por lo que la solución para esta versión 1.1 es simplemente agregar una barra + el nombre del departamento en el cuadro combinado. En la versión 2, optaríamos por reemplazar el cuadro combinado con un cuadro combinado que tenga soporte de columna, eliminando la barra oblicua, pero en 1.1, esto es lo que se elige para minimizar el riesgo de más errores.

En otras palabras, el cuadro combinado contendría:

• 1 - Jimmy Olson / Ventas
• 2 - Jimmy Olson / Desarrollo
• • otras personas

Sin embargo, el código de la interfaz de usuario no tiene código SQL, ni ninguna forma de obtener ese departamento, por lo que tenemos que ir al controlador y mirar el código allí. El controlador no necesita el departamento, y para ser honesto, ni siquiera necesita el nombre del empleado, el número de identificación es suficiente, por lo que no hay nada en el controlador que solicite o haga algo al departamento. Entonces tenemos que bajar a la capa de acceso a datos y cambiar el SQL allí.

Esta solución huele francamente.

Si hay varias interfaces para este controlador, con diferentes requisitos, tenemos tres soluciones posibles:

1. Cambie la capa de acceso a datos para satisfacer las necesidades (crecientes / diversas) de múltiples interfaces (a 2 capas de distancia), lo que significa que todas las interfaces posiblemente obtendrán todos los datos que necesitan, pero también obtendrían todos los datos requerido para cualquiera de las otras interfaces
2. Agregue algo que permita que la interfaz de usuario le diga a la capa de acceso a datos (aún a 2 capas) lo que necesita
3. De alguna manera, haga que la capa de interfaz de usuario obtenga los datos requeridos sin cambiar el controlador o la capa de acceso involucrada, esto parece que necesitamos más código de acceso a datos, en algún lugar.

Ninguna de las soluciones anteriores se siente bien.

Lo que me pregunto es, ¿estamos completamente fuera de curso? ¿Cómo harías esto? ¿Hay una cuarta y quinta solución debajo de las 3 anteriores?

Por esta pregunta: Separación de preocupaciones , la respuesta aceptada contiene esta cita:

  

La separación de inquietudes es mantener el código para cada una de estas inquietudes por separado. Cambiar la interfaz no debería requerir cambiar el código de lógica de negocios, y viceversa.

¿Esto simplemente significa que todo el controlador / capa de acceso a datos

Answer 1

A mi modo de ver, tienes dos posibilidades:

1. Haga que las capas inferiores envíen todas la información que tienen sobre un persona, posiblemente como documento XML, a pesar de que muchos de los consumidores de esa información no la necesita toda.
2. Proporcionar API para el nivel superior capas para profundizar y obtener el información que necesitan. Entonces en el caso de dar, tenga un método que la interfaz puede preguntar al negocio capa para pedir la capa de base de datos para el departamento proporcionó la identificación de usuario.

Ambos tienen compensaciones. El primero expone mucha más información, posiblemente a consumidores que no tienen ningún derecho a esa información. El segundo pasa mucha menos información por transacción, pero requiere más transacciones. El primero no requiere un cambio en la API cada vez que tiene más información, pero cambia el XML. El segundo mantiene la interfaz de las API existentes igual, pero proporciona nuevas API a medida que cambian las necesidades. Y así sucesivamente.