Suddivisione dei livelli dell'applicazione in diversi gruppi

Question

C'è un dibattito in corso nella mia azienda. Alcuni sostengono lo spostamento di business, dati e entità aziendali in un unico gruppo per

• Scopi di visibilità. rendere più facile trovare ciò che stai cercando.
• ridurre il numero di dll abbiamo bisogno di aggiungere un progetto per lo sviluppo

Altri citano la guida architettura applicativa vuole ogni strato e le entità di business in un assembly separato.

prega di notare che

• I nostri livelli di business e dati entrambi sono costituiti da componenti COM +.
• La nostra attuale architettura hardware ha web, business e dati nella stessa casella.
• SQL su una casella diversa.
• Attualmente non stiamo usando il controllo delle versioni di dll perché è in gran parte inutile con com + comunque.

Alcuni di uso hanno la sensazione che dovremmo dividere il nostro biz, i dati e le entità, ma sono a corto di ragioni.

• ridurre il consumo di memoria Potenzialmente
• Incoraggiare architettura corretta avendo solo assiemi livello aziendale aggiunti ai progetti web. Se sono disponibili anche i servizi dati, rende facile fare le cose nel modo sbagliato
• Quando dividiamo il nostro server web dai livelli aziendali e di dati, non dovremo installare crap di cui non abbiamo bisogno da un assemblaggio di dio .

In questo momento abbiamo circa 600 dll nel nostro sistema. Quindi siamo ad un estremo in cui tutto è diviso. C'è un certo consolidamento che può accadere, ma ciò che viene proposto ci sta portando ad un estremo estremo in cui ogni applicazione è in una dll.

Posso ottenere una prospettiva esterna su questo problema comune?

Grazie!

Answer 1

DLL o assiemi sono unità di distribuzione.

1. Se il codice in un particolare spazio dei nomi o classe è così strettamente associato ad un altro spazio dei nomi o classe, allora dovrebbe essere nella stessa unità di distribuzione. Se il codice nel file foo. * Non verrà mai utilizzato senza il codice richiesto nella barra. * File, potresti anche costruirli nella stessa unità di distribuzione.
2. Se uno spazio dei nomi o un gruppo di classi rappresenta un componente riutilizzabile (vale a dire che il codice viene utilizzato in due o più prodotti/applicazioni), allora è un buon candidato essere versione separata ed essere la propria unità di distribuzione.

Per me si tratta principalmente di coesione, accoppiamento e riutilizzo.
Mi piacciono le classi in una particolare unità di distribuzione per essere coese, non mi piace l'accoppiamento tra unità di distribuzione (preferirei quasi sempre che ci fossero dipendenze su una terza unità di distribuzione che contiene interfacce tali che l'accoppiamento si realizza attraverso le dipendenze su astrazioni piuttosto che concrezioni). Riutilizzare è la chiave per me quando si prendono decisioni sulle unità di distribuzione. Se il codice verrà utilizzato in più applicazioni/prodotti, deve essere un'unità di distribuzione separata con il proprio numero di versione che è separato dal numero di versione dell'applicazione.

Answer 2

L'obiettivo della nostra squadra è avere il minor numero possibile di assemblaggi. Oltre ai vantaggi elencati, ho anche scoperto che è più facile gestire gli incubi delle versioni DLL quando c'è un numero minore di DLL. L'utilizzo di un numero eccessivo di assiemi introduce inoltre il rischio di creare riferimenti circolari tra gli assiemi.

Non facciamo il possibile per inserire codice in un assembly a cui non appartiene. Ma sicuramente non creiamo un nuovo assembly senza una solida ragione per farlo. In genere abbiamo un assembly per la logica condivisa dell'applicazione (oggetti business, ecc.) E un assembly per l'interfaccia utente (l'assembly Web, l'assembly WinForms, ecc.). Inoltre, non duplichiamo codice/classi tra gli assembly solo per evitare la creazione di un nuovo assembly.

Answer 3

La suddivisione sui limiti di implementazione fisica è una buona idea. Se si dispone di componenti che possono essere ospitati per l'utilizzo remoto, un assembly separato ha senso. Questa è probabilmente la linea più semplice e solida su cui puoi dividere, per i principianti. Ci sono alcuni casi in cui il desidera il livello web per includere sia i servizi aziendali che il codice di accesso ai dati, ad esempio.

Da lì, provare a ridurre gli assiemi a cose che hanno senso alla versione indipendentemente. Se devi sempre copiare più di 10 assembly, allora probabilmente dovrebbero essere costruiti come uno.