Ho alcune domande sulla "migliore" architettura di base dei progetti software. So che ci sono diversi post simili ma sono davvero confuso perché sembra che tutti stiano dicendo qualcosa di completamente diverso o spesso con un esempio astratto che è difficile da applicare ai progetti del mondo reale.
In dettaglio, i termini Rich Domain Model e 3-layer-architecture mi stanno consigliando.
Quindi, svilupperò un progetto WebApi che verrà utilizzato da più client (iOS, Android, Web (forse MVC o SPA)).
Ho pensato che l'architettura dovesse essere simile a questa (con un modello di dominio anemico):
- DAL (livello di persistenza, solo metodi per recuperare e scrivere in DB, lavorare con POCO)
- Livello di business logic / livello di servizio (dovrebbe contenere tutte le logiche di business, anche lavorare con gli stessi POCO (?) e fare operazioni come il calcolo su di essi)
-
WebAPI (non sono sicuro quali metodi dovrebbero rimanere qui, Se WebAPI espone tutti i metodi da Business Layer? Sembra un sacco di codice duplicato)
-
Client (solo comunicazioni con WebAPI)
Ora ho sentito parlare molto del Rich Domain Model in passato e che questo approccio è migliore dove il modello contiene tutte le logiche di business.
Ora sono davvero incerto su come questo si inserisca nell'architettura a 3 livelli. La BLL ora è obsoleta?
O ha un BLL con metodi come questo (organizzazione e chiamata dei metodi del modello)
public void Transfer(BankAccount account1, BankAccount account2, int amount)
{
account1.Widthdraw(amount);
account2.AddMoney(amount);
Mail.SendInfoMail();
}
E dove dovrebbero appartenere Metodi come Excel-Export (Logica dell'applicazione)?
Forse qualcuno è in grado di migliorare la mia comprensione di questi concetti.
Un'altra domanda è: quali oggetti saranno usati in diversi livelli? Dovrei lavorare con gli oggetti del dominio in tutti i livelli superiori e restituire solo DTO da WebAPI per i client con cui lavorare? Non voglio mappare ogni oggetto a un altro oggetto in altri livelli.
Grazie!