Best practice per l'architettura di progetti - lato server [chiuso]

Naviga le tue risposte
1

Il solito modo (che ho familiarità con) per dividere il lato server è l'architettura n-layer:

  1. DAL - livello di accesso ai dati, di solito ha le Entità e il contesto (e forse include anche un repository)
  2. BLL - livello della logica aziendale
  3. Contratto - Interfacce
  4. Servizi : classi che implementano le interfacce (potrebbe essere un'API Web per E.G)

Naturalmente c'è anche l'architettura n-tier che non voglio discutere.

ultimamente ho visto sempre più un'architettura di "Moduli" e me ne stavo chiedendo (non ho familiarità con il termine professionale di questa architettura)

Dove ogni modulo non è una tabella nel database ma un gruppo di tabelle che hanno un concetto condiviso.

qualcosa che assomiglia a questo:

Esiste una buona architettura nota che separi i livelli in base ai moduli sul lato server? in tal caso, qual è il termine professionale per questo tipo di architettura e quali sono i vantaggi / svantaggi di ciascuna di queste architetture?

    
posta jony89 15.04.2014 - 10:45
fonte

1 risposta

1

Is there any known good architecture that separate the layers by modules on the server side?

Moduli e livelli sono due concetti diversi. I layer vengono in genere utilizzati per descrivere il modo in cui il codice viene distribuito in un ambiente. Tuttavia, i moduli riguardano l'organizzazione del codice in base alla funzionalità. Ci sono altre prospettive per i moduli in cui potrebbe basarsi sulle necessità del progetto, sull'ordine di rilascio ecc. La linea di fondo è che il modulo è un meccanismo di organizzazione del codice in un layout di soluzione.

What is the professional term for this kind of architecture and what are the advantages / disadvantages of each of this architectures

Non sono a conoscenza di un termine professionale per l'organizzazione del codice mostrato nell'immagine. Tuttavia, lasciami trasmettere ciò che penso sull'immagine. È una semplice tecnica di organizzazione del codice in una soluzione. Ha ben poco a che fare con l'architettura. D'accordo, l'organizzazione del codice fa parte dell'architettura. Ma non sono sicuro se esiste una nomenclatura per questo. La mia opinione su un'organizzazione di questo tipo sarebbe

  • Il progetto si concentra più sull'organizzazione funzionale del codice che indica un dominio ricco. Le persone in squadra comprendono molto meglio il dominio. Pertanto, il team potrebbe aver trovato questa organizzazione più naturale.

  • Lo svantaggio di questo tipo di organizzazione del codice è costituito da molti progetti C #. Invece di avere un progetto per tutti i contratti e sottocartelle basati sui moduli, stai progettando progetti per ciascuna funzionalità che verranno successivamente uniti insieme.

  • Un altro svantaggio che ho notato è che molti degli assembly coinvolti potrebbero trascinare il rendimento.

Spero che questo aiuti.

    
risposta data 15.04.2014 - 12:42
fonte

Leggi altre domande sui tag

Che tipo di processi o alays statici useresti per catturare bug di buffer improprio come quello che ha causato problemi di cuore? [chiuso] Interfacce go-like + multi-metodi hanno senso?