2009-07-29 14 views
5

Progetterò a breve un paio di applicazioni web. Probabilmente saranno fatti in asp.net mvc.Le applicazioni Web di mvc dovrebbero essere a 3 livelli?

Nelle mie app Web esistenti, eseguite in delphi, il livello di accesso ai dati è separato in un'applicazione completamente separata, a volte in esecuzione su un server diverso. Questo viene fatto più per il riutilizzo del codice che per ragioni architettoniche. Questo non sarà un fattore nella prossima app in quanto sarà tutto nuovo.

L'overkill dell'applicazione di accesso ai dati è separato in un'app mvc? Separerò già le classi di business grazie all'utilizzo di MVC e userò un ORM per eseguire la persistenza del database.

Modifica: Giusto per chiarire; Uso il termine tier per riferirsi a applicazioni fisiche separate, qualcosa di più di una semplice separazione o strato logico.

+2

Se si separano classi buisiness e DB per persistenza, si dispone già di almeno 3 livelli. GUI/Logic/DB: si tratta di 3 livelli in modo da non ottenere n <3. Introduci un livello aggiuntivo se hai bisogno di più modularizzazione, ma dipende interamente dalla tua applicazione. –

risposta

6

Il termine "Tier" nella mia esperienza è generalmente riferendosi a separazioni di applicazioni fisiche per esempio Livello server & server.

MVC - si riferisce a 3 "Strati" con la preoccupazione che è la separazione attorno al 3 riguarda dettagli Modello (dati), View (UI), Controller (App Logic).

Ora che ho fatto questa distinzione per quanto riguarda il mio terminologia ..

sta avendo un accesso ai dati dell'applicazione eccessivo separata in un'applicazione MVC?

direi No (sempre a seconda che cosa si intende per applicazione), non è eccessivo, come sia in effettivo risultato infatti in un sistema più gestibile. Il tuo ORM sarà possibilmente consentire l'inserimento di nuove opzioni di accesso ai dati, ma cosa succede se desideri aggiungere un nuovo ORM? Avere un DAL (Data Access Layer) chiaramente separato consente una maggiore flessibilità futura in questo aspetto dell'applicazione.

D'altra parte, a seconda della scala e della visione dell'applicazione che crea un'opzione di accesso ai dati completamente autonoma, può essere eccessivo, ma in una separazione semplice del DAL in diversi gruppi è una pratica consigliata nella composizione di un'applicazione che implementa il pattern MVC.

Spero che questo aiuti, se avete bisogno di più profondità, commentare.

0

Ottimo commento Tobias.

Direi aggiungere abbastanza strati in modo che abbia senso per voi e rende più facile da mantenere. Anche per mantenere una separazione delle preoccupazioni.

2

Beh io gues, dipende un po 'dal fatto che si stia parlando livelli (Abilità fisiche) o strati (logici/progetti).

Per quanto riguarda la stratificazione, è possibile dare un'occhiata a qualcosa come l'architettura s arp (code.google.com/p/sharp-architecture/) per un esempio di come lo fanno (hanno adottato un approccio piuttosto semplice alla stratificazione).

Per un esempio di punti di vista più minimalista qui, un'occhiata al blog di Ayende: ayende.com/Blog/

Per quanto riguarda piani - Credo che inutilmente l'aggiunta di livelli aggiuntivi e mettendo everthing sopra il filo sarà solo colpire le vostre prestazioni , a meno che non sia necessario farlo per motivi di capacità. Ottieni gli strati giusti, e li separano in teirs in quanto è necessario regolare la capacità (non dovrebbe richiedere troppi refactoring se hai separato bene le tue preoccupazioni).

Problemi correlati