J'ai une application web. Je ne crois pas que la technologie soit importante. La structure est une application à N niveaux, illustrée dans l'image de gauche. Il y a 3 couches.
UI (modèle MVC), Business Logic Layer (BLL) et Data Access Layer (DAL)
Le problème que j'ai est mon BLL est énorme car il a la logique et les chemins à travers l'appel aux événements d'application.
Un flux typique dans l'application pourrait être:
Événement déclenché dans l'interface utilisateur, traverser vers une méthode dans le BLL, exécuter la logique (éventuellement dans plusieurs parties du BLL), éventuellement vers le DAL, revenir au BLL (où probablement plus de logique), puis renvoyer une valeur à l'interface utilisateur.
Le BLL dans cet exemple est très occupé et je pense comment le répartir. J'ai aussi la logique et les objets combinés que je n'aime pas.
La version de droite est mon effort.
La logique est toujours la façon dont l'application circule entre l'interface utilisateur et DAL, mais il n'y a probablement aucune propriété ... Seules les méthodes (la majorité des classes de cette couche peuvent être statiques car elles ne stockent aucun état). La couche Poco est l'endroit où existent des classes qui ont des propriétés (comme une classe Person où il y aurait le nom, l'âge, la taille, etc.). Ceux-ci n'auraient rien à voir avec le flux de l'application, ils ne stockent que l'état.
Le flux pourrait être:
Même déclenché à partir de l'interface utilisateur et transmet certaines données au contrôleur de couche UI (MVC). Cela traduit les données brutes et les convertit en modèle poco. Le modèle poco est ensuite transmis à la couche Logic (qui était le BLL) et finalement à la couche de requête de commande, potentiellement manipulé en cours de route. La couche de requête Command convertit le POCO en un objet de base de données (qui sont presque la même chose, mais l'un est conçu pour la persistance, l'autre pour le frontal). L'élément est stocké et un objet de base de données est renvoyé à la couche de requête de commande. Il est ensuite converti en POCO, où il retourne à la couche Logic, potentiellement traité plus loin, puis enfin, de retour à l'interface utilisateur
La logique et les interfaces partagées est l'endroit où nous pouvons avoir des données persistantes, telles que MaxNumberOf_X et TotalAllowed_X et toutes les interfaces.
La logique / les interfaces partagées et le DAL sont tous deux la "base" de l'architecture. Ceux-ci ne savent rien du monde extérieur.
Tout sait sur poco autre que la logique / interfaces partagées et DAL.
Le flux est toujours très similaire au premier exemple, mais cela rend chaque couche plus responsable d'une chose (que ce soit l'état, le flux ou autre) ... mais suis-je en train de rompre la POO avec cette approche?
Un exemple de démonstration de Logic et Poco pourrait être:
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;
}
}