modello mvc: modello di suddivisione in livelli di accesso ai dati e di logica aziendale

6

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)

  1. 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 ...

  2. 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:

  1. 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
  2. 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
  3. 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:

  1. più cluttering a causa dell'aggiunta di un intero nuovo livello di classi al sistema
  2. prestazioni leggermente inferiori a causa dell'iniezione di dipendenza aggiunta che richiede tempo per risolvere
  3. 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

    
posta Ajant 03.06.2013 - 14:03
fonte

2 risposte

5

MVC significa separazione modello-vista-controller per il lato client, in questo caso il tuo sito. Non ha nulla a che fare con la stratificazione backend.

Riguardo alla stratificazione del backend; Mi piace personalmente l'approccio onion come descritto qui e applicato < a href="http://ludwigstuyck.wordpress.com/2013/03/05/a-reference-architecture-part-1/"> qui . Il livello aziendale è indipendente dall'implementazione del livello dati o da qualsiasi altro aspetto tecnico, in quanto conosce solo le interfacce.

Quindi nel tuo controller usi i servizi di back-end (nota che non sto dicendo servizi WCF - può essere WCF, ma non deve esserlo). Ottieni i dati in un formato specifico (il modello) e poi puoi trasformare questi dati in viewmodels progettati specificamente per una vista.

I servizi di backend avranno quindi i vari livelli necessari per implementare l'architettura scelta (livello aziendale, livello dati, ecc.), ma questo è indipendente dal tuo sito ASP.NET MVC.

E non evitare di usare l'iniezione di dipendenza per i motivi sbagliati. Dovrebbe essere lo stile di programmazione predefinito.

    
risposta data 03.06.2013 - 14:15
fonte
0

I tuoi istinti sono buoni, ma non penso che dovrebbero far parte del pensiero di MVC più, perché sia la business logic che l'accesso ai dati dovrebbero essere indipendenti dalla vista. Dovresti essere in grado di riutilizzarli entrambi indipendentemente dal fatto che vengano visualizzati utilizzando browser, desktop, tablet o dispositivo mobile.

Penso che rientri nella categoria del layering appropriato per un'architettura orientata ai servizi.

I servizi non hanno bisogno di SAPONE; le scelte di implementazione sono separate. Questi sono oggetti basati su interfaccia.

Quello che tu chiami "business logic" è quello che io considero il livello di servizio. Non sono d'accordo con la dichiarazione sulla logica di business che non conosce il livello di persistenza. La logica aziendale deve conoscere il livello di persistenza, poiché deve gestire le transazioni come unità di lavoro.

Inoltre non sono d'accordo con "le prestazioni inferiori dovute all'iniezione di dipendenza aggiunta". Questo dovrebbe essere fatto all'avvio e non avrà un effetto misurabile sulle medie a lungo termine. È ammortizzato su tutte le chiamate al servizio.

Sia i livelli di servizio che quelli di persistenza dovrebbero essere basati sull'interfaccia.

    
risposta data 03.06.2013 - 14:12
fonte

Leggi altre domande sui tag