Ho avuto la possibilità di provarlo e mi piace molto. Sto pensando di usarlo in tutti i miei progetti futuri. Mi piacerebbe sentire alcune critiche e opinioni a riguardo. Ho fatto una piccola ricerca sull'argomento e non sono sicuro di aver visto questo approccio in giro, ma sono abbastanza sicuro che dev'essere stato provato da persone più esperte e vorrei evitare qualsiasi insidia che viene con esso
L'idea è che il modello sia suddiviso in: 1. livello di accesso db (dal) 2. livello logico aziendale (bll)
-
quindi il livello di accesso db contiene (idealmente) nessuna logica a tutti gli altri della logica di accesso db - query preparate fornite con parametri, quando chiamate, e quali risultati restituiti da db, se necessario (nel caso di query SELECT ). queste classi non sono testate (se nessuna logica è inserita in esse), poiché non contengono alcun comando if / for / while / throw ...
-
livello della logica aziendale che contiene la logica effettiva dell'app. i controllori non vedono dal e chiamano solo bll che a sua volta chiama dal quando necessario. bll ha bisogno di essere testato (io uso il test delle unità) e poiché è tenuto separato dall'accesso db, quando viene testata la funzionalità di sola lettura, l'accesso db può essere deriso usando l'iniezione di dipendenza (creare una classe di simulazione alternativa per ogni classe dal gli stessi metodi, caricarli tramite il metodo factory quando richiesto da bll e a seconda che la chiamata provenga dall'ambiente di testing o non carichi la classe mock o 'real'. ovviamente in caso di funzionalità di scrittura (DELETE, INSERT), il test verrebbe devono includere le chiamate db, quindi in tal caso verrebbe chiamata la 'vera' classe, piuttosto che il mock, ma questo può essere ancora molto utile se il sistema ha più read quindi scrive le chiamate db
Benefici di questo approccio:
- separazione dei codici - mantiene pulita la logica aziendale del codice di accesso db che migliora la leggibilità, specialmente nei metodi di grandi dimensioni che devono effettuare diverse chiamate a db. semplifica il mantenimento del codice e consente inoltre di incapsulare la logica di accesso db, che può essere chiamata da un numero di blls che facilita anche la manutenzione di
- rende più facile cambiare database in qualsiasi momento, il che non è qualcosa che accade spesso, ma se succede, non è una cosa facile da fare, tutti quelli che dovevano farlo ad un certo punto sanno cosa sono parlando di
- quando si provano bll con le classi mock, i test vengono eseguiti più velocemente poiché non vengono effettuate chiamate a db. questo non è troppo significativo, ma può essere d'aiuto quando si modificano intensivamente alcune funzionalità e si verificano durante il processo. allo stesso tempo rende molto più semplice testare le prestazioni della "pura logica" scollegata dalle chiamate db
inconvenienti:
- più cluttering a causa dell'aggiunta di un intero nuovo livello di classi al sistema
- prestazioni leggermente inferiori a causa dell'iniezione di dipendenza aggiunta che richiede tempo per risolvere
- mentre le classi di simulazione fanno un buon lavoro, devono essere create e mantenute in modo da aggiungere ulteriore burocrazia all'intero sistema
Mi manca qualcosa? Preferisci il sistema che ho descritto o il buon vecchio mvc di moda 3 strati e perché? Non sono un guru, sto ancora esplorando varie architetture, ma mi piace molto e mi piacerebbe sapere cosa ne pensano i miei colleghi più esperti