Stavo discutendo di una mia struttura di progetto con un amico e lui ha sottolineato un punto interessante su come la mia architettura sembra introdurre complessità e astrazione nei miei strati avendo "cloni" di modelli esistenti.
La struttura del mio progetto, in generale, è tale:
[UIL] ---- Consumption / U.I. Layer (Just for the sake of completeness with respect to the architecture’s explanation)
- Models (ViewModels & Mapping)
- Controllers
- Views
[API] ---- Service/API Layer (We call it the API layer because we use actual services from others that would be confusing if we called our stuff services & clash...so we call these classes with the suffix of Api (i.e. UserApi, ProductApi)) (coordinates the lower level calls & interactions into consumable higher level facades)
- Api Models (Initial properties are the same to that of DTO models) (Rich Domain Models that utilize dependency injection to BLL api's, these are passed to Consumption / UI Layer if needed)
- Interfaces(self-explanatory)
- Adapters
- Api's / Services
- Mixins
[BLL] ---- Business Logic Layer (Domain)
- Models (holds specific business logic rules & properties & engine references for corresponding api models that should not be publicly exposed)
- Interfaces
- Engines
[DAL] ---- Data Access Logic Layer
- Models (Database matching anemic DTO's)
- Interfaces (...)
- Connections
- Factories
- Repositories
- UnitOfWork's
- Contexts
Rileva che ho più "cloni" dei modelli originali dal mio DB / DAL dal fatto che ognuno dei modelli DAL, BLL e API mantiene le stesse proprietà l'uno nell'altro (di solito non tutte, ma si collegano tutti insieme tramite alcuni). Penso tuttavia che progrediscano bene da anemico (solo per le interazioni Database) a ricchi "domini" complessi con metodi completamente svuotati, proprietà completamente espanse, modelli collegati, api di modello collegato (dietro metodi / DI), validazione, api di logica aziendale (dietro metodi / DI), ecc. Questi possono essere tranquillamente passati a qualsiasi livello di consumo per ulteriore utilizzo o per la mappatura per visualizzare i modelli.
-
Non vedo un motivo per intasare i miei anemici modelli DAL con la logica in questi modelli perché nulla dovrebbe mai sapere del mio DAL diverso dal livello API / Servizio. Corretta? Anche questo si rompe separazione delle preoccupazioni da quando il mio modello DAL DTO ora è mappato a database, business logic, view, ecc. e possono essere rimandati al database ... o in qualche modo, mi manca qualcosa?
-
Se utilizzo i miei modelli DAL per qualsiasi cosa, il mio livello di consumo / interfaccia utente farebbe riferimento a DAL.Models.Product per esempio e ora il mio DAL è esposto. Questa è l'antitesi della separazione di & disaccoppiare gli strati, giusto? Se la mia comprensione è corretta, nulla al di sopra del livello API / Service dovrebbe sapere qualcosa sotto di esso (ad esempio DAL, BLL e / o altri livelli sotto), corretto?
-
I modelli di Api sono più completamente personalizzati rispetto a ciò che un livello di consumo vorrebbe vedere rispetto a un database (cioè senza ID estranei, classi "entità", avevano un comportamento chiaramente modellato tramite metodi, DI API, ecc.), questo rende il front-end disaccoppiato dal back-end se cambia, corretto? Inoltre, si interfacciano piacevolmente con ViewModels semplicemente per utilizzarli come ViewModel o tramite mappatura rapida su un modello di visualizzazione.
Non sto dicendo che ho ragione o che il mio amico ha ragione, ma ha sollevato un punto interessante che volevo esplorare. Finora la ricerca è in qualche modo sporadica con persone in molti campi diversi.