Ich habe eine Webanwendung. Ich glaube nicht, dass die Technologie wichtig ist. Die Struktur ist eine N-Tier-Anwendung (siehe Abbildung links). Es gibt 3 Schichten.
Benutzeroberfläche (MVC-Muster), Business Logic Layer (BLL) und Datenzugriffsschicht (DAL)
Das Problem, das ich habe, ist, dass meine BLL massiv ist, da sie die Logik und Pfade für den Aufruf der Anwendungsereignisse aufweist.
Ein typischer Fluss durch die Anwendung könnte sein:
In der Benutzeroberfläche ausgelöstes Ereignis, Übergang zu einer Methode in der BLL, Logik ausführen (möglicherweise in mehreren Teilen der BLL), schließlich zur DAL, zurück zur BLL (wo wahrscheinlich mehr Logik vorhanden ist) und dann einen bestimmten Wert an die Benutzeroberfläche zurückgeben.
Die BLL in diesem Beispiel ist sehr beschäftigt und ich überlege, wie ich das aufteilen kann. Ich habe auch die Logik und die Objekte kombiniert, die ich nicht mag.
Die Version auf der rechten Seite ist meine Anstrengung.
Die Logik ist immer noch der Ablauf der Anwendung zwischen Benutzeroberfläche und DAL, aber es gibt wahrscheinlich keine Eigenschaften ... Nur Methoden (die meisten Klassen in dieser Ebene können möglicherweise statisch sein, da sie keinen Status speichern). In der Poco-Ebene gibt es Klassen mit Eigenschaften (z. B. eine Personenklasse, in der Name, Alter, Größe usw. angegeben sind). Diese haben nichts mit dem Ablauf der Anwendung zu tun, sondern speichern nur den Status.
Der Fluss könnte sein:
Wird sogar über die Benutzeroberfläche ausgelöst und übergibt einige Daten an den UI-Layer-Controller (MVC). Dadurch werden die Rohdaten übersetzt und in das Poco-Modell konvertiert. Das POCO-Modell wird dann an die Logikebene (die die BLL war) und schließlich an die Befehlsabfrageebene übergeben, die möglicherweise unterwegs manipuliert wird. Die Befehlsabfrageebene konvertiert das POCO in ein Datenbankobjekt (das fast dasselbe ist, aber eines ist für die Persistenz vorgesehen, das andere für das Front-End). Das Element wird gespeichert und ein Datenbankobjekt wird an die Befehlsabfrageebene zurückgegeben. Es wird dann in ein POCO konvertiert, wo es zur Logikebene zurückkehrt, möglicherweise weiterverarbeitet wird und schließlich zur Benutzeroberfläche zurückkehrt
In der gemeinsam genutzten Logik und den Schnittstellen sind möglicherweise persistente Daten enthalten, z. B. MaxNumberOf_X und TotalAllowed_X sowie alle Schnittstellen.
Sowohl die gemeinsame Logik / Schnittstelle als auch DAL bilden die "Basis" der Architektur. Diese wissen nichts über die Außenwelt.
Alles andere als die gemeinsame Logik / Schnittstellen und DAL weiß über Poco.
Der Ablauf ist dem ersten Beispiel immer noch sehr ähnlich, aber es hat jede Ebene für eine Sache verantwortlicher gemacht (sei es der Zustand, der Ablauf oder irgendetwas anderes) ... aber breche ich die OOP mit diesem Ansatz?
Ein Beispiel für die Demo von Logic und Poco könnte sein:
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;
}
}