Quanti strati sono troppi?

Question

Come ho imparato a conoscere lo sviluppo del software negli ultimi 2 anni, più imparo, sembra che più aree grigie mi stiano incontrando. Un'area grigia con cui ho problemi al momento sta cercando di decidere quanti livelli deve avere un'applicazione. Ad esempio, in un'applicazione MVVM WPF quale stile di stratificazione è corretto? Anche il seguente è separato? Quando dico stratificazione, intendo creare una nuova libreria di classi per ogni livello.

• Presentazione (View)
• View Modello
• Business Layer
• accesso ai dati
• layer Modello
• Utility layer

O per un'applicazione non MVVM è anche questo separato?

• Presenation
• Affari
• accesso ai dati
• layer Modello
• Utility layer

è accettabile per eseguire gli strati insieme e basta creare cartelle per ogni strato? Sarebbe gradita qualsiasi colorazione di questa area grigia.

Answer 1

Layered Architecture: Questo articolo descrive un'architettura di esempio concreta per applicazioni Rich Client .NET/WPF. Inoltre, l'architettura mostra in quale livello si trovano i partecipanti del modello Model-View-ViewModel (MVVM).

Answer 2

La risposta è: dipende. Prima di tutto, una libreria di classi separata non significa sempre un "livello" separato. Un livello è un raggruppamento concettuale di funzionalità correlate, che può o meno manifestarsi in un singolo assieme.

Quanti strati si crea è davvero dipende dal vostro problema a portata di mano. Tradizionalmente, un'applicazione MVVM WPF conterrà almeno i 3 livelli (Modello, Visualizza, Visualizza modello) ma può essere davvero variata. Spesso volte vedo Views e ViewModels nello stesso assembly e nei modelli nel proprio assembly (di solito perché gli oggetti Model sono POCO che vengono utilizzati in altri contesti)

Non c'è davvero un proiettile d'argento che risponda alla tua domanda, dipende interamente dal tuo problema. Il vantaggio di "stratificazione" e separazione è quello di aumentare la manutenibilità, promuovere il riutilizzo del codice e aumentare la chiarezza generale (per citarne alcuni).

direi che se non stanno raggiungendo questi obiettivi con la soluzione di stratificazione corrente allora si ha spazio per migliorare. Se aumentando gli strati è diminuendo la chiarezza o manutenibilità allora siete andati troppo lontano. Se hai solo un singolo "livello" e sta diventando gonfio, allora hai l'opportunità di aggiungere un livello.

La linea di fondo è di non più di ingegnere qualcosa per il bene di seguire un rigoroso "modello". Se il modello presenta chiari vantaggi per te e il tuo problema, implementalo, ma comprendi perché lo stai facendo e qual è l'obiettivo di ogni "livello".

Answer 3

considerare le seguenti aree:.

• velocità
• Riusabilità
• leggibilità
• Il tempo di sviluppo
velocità
• Modification (le parole giuste per descrivere questo punto mi stanno scappando Edit - Maintainability era quello che stavo cercando [rubato da qualcun altro risposta])
• Impronta applicazione (scala e l dimensioni curartene)
• Il vostro team di sviluppo

... quindi regolare l'architettura basata su quale di questi si valore. Probabilmente mi mancano alcune altre parti importanti, ma tu hai l'idea. Non c'è davvero nessuna risposta giusta o sbagliata a questo.

Answer 4

Un'applicazione ha troppi strati solo se i livelli stessi diventano un ostacolo alla manutenibilità del progetto anziché migliorare la manutenibilità.

Answer 5

Il numero esatto di livelli che è troppi è 1 in più del necessario.