Ho un'applicazione web. Non credo che la tecnologia sia importante. La struttura è un'applicazione di livello N, mostrata nell'immagine a sinistra. Ci sono 3 livelli.
UI (modello MVC), Business Logic Layer (BLL) e Data Access Layer (DAL)
Il problema che ho è che il mio BLL è enorme in quanto ha la logica e i percorsi attraverso la chiamata degli eventi dell'applicazione.
Un flusso tipico attraverso l'applicazione potrebbe essere:
L'evento generato nell'interfaccia utente, attraversa un metodo nel BLL, esegue la logica (possibilmente in più parti del BLL), infine al DAL, di nuovo al BLL (dove probabilmente più logica) e quindi restituisce un valore all'interfaccia utente.
Il BLL in questo esempio è molto impegnato e sto pensando a come dividerlo. Ho anche la logica e gli oggetti combinati che non mi piacciono.
La versione a destra è il mio sforzo.
La logica è ancora il modo in cui l'applicazione scorre tra UI e DAL, ma probabilmente non ci sono proprietà ... Solo metodi (la maggior parte delle classi in questo livello potrebbe essere statica in quanto non memorizzano alcuno stato). Il livello Poco è dove esistono le classi che hanno proprietà (come una classe Person dove ci sarebbero nome, età, altezza ecc.). Questi non avrebbero nulla a che fare con il flusso dell'applicazione, immagazzinano solo lo stato.
Il flusso potrebbe essere:
Anche attivato dall'interfaccia utente e passa alcuni dati al controller di livello dell'interfaccia utente (MVC). Questo traduce i dati grezzi e li converte nel modello poco. Il modello poco viene quindi passato al livello Logic (che era il BLL) e infine al livello query dei comandi, potenzialmente manipolato lungo il percorso. Il livello di query Command converte il POCO in un oggetto database (che sono quasi la stessa cosa, ma uno è progettato per la persistenza, l'altro per il front-end). L'elemento viene archiviato e un oggetto database viene restituito al livello Query comandi. Viene quindi convertito in un POCO, dove ritorna al livello Logic, potenzialmente elaborato ulteriormente e, infine, torna all'interfaccia utente
La logica e le interfacce condivise sono dove possiamo avere dati persistenti, come MaxNumberOf_X e TotalAllowed_X e tutte le interfacce.
Sia la logica / interfacce condivise che DAL sono la "base" dell'architettura. Questi non sanno nulla del mondo esterno.
Tutto sa poco oltre alle logiche / interfacce condivise e DAL.
Il flusso è ancora molto simile al primo esempio, ma ha reso ogni livello più responsabile di 1 cosa (sia esso stato, flusso o qualsiasi altra cosa) ... ma sto rompendo OOP con questo approccio?
Un esempio per demo di Logic e Poco potrebbe essere:
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;
}
}