Capire l'architettura di un progetto

Question

Capire l'architettura di un progetto

#1 da (5 voti)

1

Se sviluppo un'applicazione, userò spesso una struttura di progetto come questa:

MyApp.DataAccess.Implementation
MyApp.DataAccess.Contract
MyApp.Business.Implementation
MyApp.Business.Contract 
MyApp.CrossCutting.Implementation
MyApp.CrossCutting.Contract
MyApp.Application

Per ogni livello creerò due assiemi. Uno per le interfacce e uno per l'implementazione stessa. Nel livello "CrossCutting" è tutto come la registrazione, le entità, la configurazione ... Se il progetto è veramente grande, separerò ogni componente nel livello "CrossCutting" in un assieme separato. Nel livello applicazione, c'è la mia console / progetto ui / web.

Questa struttura di progetto può essere applicata facilmente su progetti più grandi. Ma per un piccolo progetto penso che questo sia troppo grande. Quindi, dopo un po 'di tempo con Google, ho trovato una struttura semplice per progetti più piccoli.

Core
Data
Domain (or BusinessObjects)
Services
Utilities (or Helpers)

Il mio problema con questa struttura è, non ho idea di ciò che questi livelli rappresentano. Qualcuno può spiegarmi questi strati?

c# architecture

posta Marcel Hoffmann 29.09.2015 - 09:12

fonte

1 risposta

Leggi altre domande sui tag c# architecture

Qual è il modo più leggibile per passare argomenti alla funzione? [chiuso] Dovresti mai mescolare comunque i contesti scalari ed elenchi?

score 5 · Answer 1

Architettura a tre livelli L'articolo di Wikipedia ne spiega già due:

Il livello di accesso ai dati (DAL) è ciò che contiene la logica direttamente associata ai dati. Ad esempio, se la tua applicazione utilizza il database Oracle e successivamente, esegui la migrazione a MongoDB, il livello di accesso ai dati è l'unico livello da riscrivere.

L'obiettivo di questo livello è di astrarre l'accesso all'origine dati sottostante per il livello aziendale. Ad esempio, può caricare dati da più tabelle e aggregarli prima di presentare un risultato conveniente da utilizzare per il livello aziendale. Un altro esempio è che il DAL può gestire il controllo della concorrenza, ovvero verificare che un'entità sia stata modificata da qualcun altro mentre un utente la stava modificando.
Il livello aziendale (BL) è ciò che di solito contiene la parte più importante della tua applicazione: la logica aziendale effettiva, il motivo per cui questa applicazione esiste in primo luogo.

Ad esempio, qui troverai le regole di contabilità o il processore delle regole se gestisci un'applicazione per i contabili o il calcolo effettivo se gestisci un'applicazione scientifica.

L'architettura a tre livelli contiene anche un terzo livello:

Presentation layer (PL), quello che si occupa della presentazione delle informazioni all'utente (nel caso di un'applicazione per l'utente finale) o del chiamante (nel caso di un servizio Web) e, inversamente, dell'elaborazione ( che significa anche igienizzare) l'input.

Come per gli altri livelli elencati nella tua domanda:

Core contiene il framework sviluppato appositamente per il tuo progetto. Ad esempio, se stai scrivendo un'applicazione web, puoi estendere il framework web esistente con le funzionalità di cui avrai bisogno in questo specifico progetto, come una riscrittura dell'URL di fantasia o la parte che carica la configurazione dell'applicazione.
I servizi sono come DAL, ma per servizi diversi. Ad esempio, se utilizzi le API di Google, puoi mettere tutta la logica che rende effettive le chiamate ai server di Google in questo livello.

Analogamente al DAL, consente di passare facilmente tra i fornitori di servizi; ad esempio, passa dall'API di Google Maps all'API di Bing Maps.
Le utilità contengono i metodi di utilità. Assicurati di leggere questo e questo per capire perché i metodi di utilità dovrebbero essere evitati se ti interessa OOP.