Sto cercando un feedback sull'architettura dell'applicazione CMS basata su ASP.NET MVC.ASP.NET MVC application guidelines "guidelines"
Modello di dominio: dipende da nient'altro che dalle classi di sistema per definire i tipi. Per ora, per lo più anemico.
Repository Strato - l'accesso ai dati astratto, chiamato solo dal livello dei servizi
Servizi Strato - esegue la logica di business in modelli di dominio. Espone i modelli di visualizzazione ai controller.
ViewModelMapper - servizio che traduce avanti e indietro tra i modelli vista e modelli di dominio
Controllori - funzionalità super sottile "vigile" stile che interagisce con il livello di servizio e parla solo in termini di modelli di vista, mai modelli di dominio
Il mio modello di dominio è utilizzato principalmente come oggetti di trasferimento dati (DTO) e al momento ha una logica minima. Sto scoprendo che questo è bello perché non dipende da nulla (nemmeno dalle classi nel livello dei servizi).
Il livello di servizi è un po 'complicato ... Voglio solo che i controller abbiano accesso a viewmodels per facilitare la programmazione della GUI. Tuttavia, alcuni servizi devono parlare tra loro. Ad esempio, ho un servizio di eventing che notifica altri servizi listener quando il contenuto viene taggato, quando vengono creati post di blog, ecc. Attualmente, i metodi che accettano i modelli di dominio come input o li restituiscono sono contrassegnati internamente in modo che non possano essere utilizzati da i controller.
Suona come eccessivo? Non abbastanza astrazione? Lo sto facendo principalmente come esercizio di apprendimento per essere rigoroso sull'architettura, non per un prodotto reale, quindi per favore nessun commento sulla falsariga di "giusto dipende da cosa vuoi fare".
grazie!
Il fatto che sei riuscito a dire così tanto in così poche parole dovrebbe darti l'idea che sei sulla strada giusta. – pdr