Tengo una aplicación web No creo que la tecnología sea importante. La estructura es una aplicación de N niveles, que se muestra en la imagen de la izquierda. Hay 3 capas
UI (patrón MVC), capa de lógica de negocios (BLL) y capa de acceso a datos (DAL)
El problema que tengo es que mi BLL es enorme, ya que tiene la lógica y las rutas a través de la llamada de eventos de la aplicación.
Un flujo típico a través de la aplicación podría ser:
Evento disparado en la interfaz de usuario, atravesar un método en el BLL, realizar la lógica (posiblemente en varias partes del BLL), eventualmente al DAL, volver al BLL (donde probablemente haya más lógica) y luego devolver algún valor a la UI.
El BLL en este ejemplo está muy ocupado y estoy pensando cómo dividir esto. También tengo la lógica y los objetos combinados que no me gustan.
La versión de la derecha es mi esfuerzo.
La lógica sigue siendo cómo fluye la aplicación entre UI y DAL, pero es probable que no haya propiedades ... Solo métodos (la mayoría de las clases en esta capa podrían ser estáticas ya que no almacenan ningún estado). La capa Poco es donde existen clases que tienen propiedades (como una clase Persona donde habría nombre, edad, altura, etc.). Estos no tendrían nada que ver con el flujo de la aplicación, solo almacenan estado.
El flujo podría ser:
Incluso se activa desde la interfaz de usuario y pasa algunos datos al controlador de capa de interfaz de usuario (MVC). Esto traduce los datos en bruto y los convierte en el modelo poco. Luego, el modelo poco se pasa a la capa Lógica (que era el BLL) y, finalmente, a la capa de consulta de comandos, potencialmente manipulada en el camino. La capa de consulta de Comando convierte el POCO en un objeto de base de datos (que son casi lo mismo, pero uno está diseñado para la persistencia, el otro para el front-end). El elemento se almacena y se devuelve un objeto de base de datos a la capa Consulta de comando. Luego se convierte en un POCO, donde vuelve a la capa Lógica, potencialmente procesada más adelante y luego finalmente, de vuelta a la IU
La lógica y las interfaces compartidas es donde podemos tener datos persistentes, como MaxNumberOf_X y TotalAllowed_X y todas las interfaces.
Tanto la lógica / interfaces compartidas como DAL son la "base" de la arquitectura. Estos no saben nada del mundo exterior.
Todo sabe poco más que la lógica / interfaces compartidas y DAL.
El flujo sigue siendo muy similar al primer ejemplo, pero ha hecho que cada capa sea más responsable de 1 cosa (ya sea estado, flujo o cualquier otra cosa) ... pero ¿estoy rompiendo la POO con este enfoque?
Un ejemplo para demostrar la lógica y Poco podría ser:
public class LogicClass
{
private ICommandQueryObject cmdQuery;
public PocoA Method1(PocoB pocoB)
{
return cmdQuery.Save(pocoB);
}
/*This has no state objects, only ways to communicate with other
layers such as the cmdQuery. Everything else is just function
calls to allow flow via the program */
public PocoA Method2(PocoB pocoB)
{
pocoB.UpdateState("world");
return Method1(pocoB);
}
}
public struct PocoX
{
public string DataA {get;set;}
public int DataB {get;set;}
public int DataC {get;set;}
/*This simply returns something that is part of this class.
Everything is self-contained to this class. It doesn't call
trying to directly communicate with databases etc*/
public int GetValue()
{
return DataB * DataC;
}
/*This simply sets something that is part of this class.
Everything is self-contained to this class.
It doesn't call trying to directly communicate with databases etc*/
public void UpdateState(string input)
{
DataA += input;
}
}