Contenuto consigliato per i livelli

1

Come espansione dalla mia precedente domanda sull'utilizzo di progetti separati per livelli separati - Buona pratica su Visual Studio Solutions

Ora desidero sapere se sto inserendo la giusta funzionalità nei livelli corretti.

Sfondo

Sto costruendo un'applicazione WPF da zero, che contiene logica aziendale e oggetti business. Il database stesso si trova su un altro server sul Web con accesso ad esso, limitato alle chiamate API Web mediante l'autenticazione OAuth.

Penso che il seguente contenuto dovrebbe essere in questi livelli. L'idea è che tu passi dal livello 1 al livello 4, solo in base agli strati sottostanti. Per evitare dipendenze circolari.

1. Presentazione

Vista WPF (ciò che vedrà l'utente)

WPF ViewModel (come il programma risponde all'interazione dell'utente)

Nessun modello WPF, poiché sarà solo l'oggetto business

2. Application / Servizi

Repository (classe utilizzata da ViewModel per caricare / salvare oggetti business)

Classi di utilità per aiutare a salvare oggetti, selezionando le chiamate API corrette.

3. Livello aziendale

Oggetti aziendali / Entità / DTO (a prescindere dal nome preferito)

Fabbriche (utilizzate dai repository nella creazione di oggetti business)

Altra altra classe di business (ad esempio, l'archiviazione dell'utente attualmente connesso)

4. Infrastruttura / Accesso ai dati

Client OAuth (effettua chiamate autenticate contro il server Web, utilizzate dalle classi di repository)

    
posta JonWillis 10.10.2011 - 10:29
fonte

3 risposte

2

I quattro livelli che hai citato corrispondono ai nomi della stratificazione che ho usato quando recentemente ho architettato due nostre soluzioni aziendali. Sono inoltre fermamente d'accordo con @Konamiman reply, Data Access e Infrastructure devono essere due livelli separati. Nelle nostre soluzioni Infrastucture è uno strato trasversale che può essere referenziato da progetti in qualsiasi livello. Nel livello infrastruttura manteniamo la funzionalità di registrazione, la sicurezza e il codice di convalida.

Vorrei anche considerare di aggiungere un livello sotto il livello di accesso ai dati chiamato Entità. Metti tutti gli oggetti business lì, aggiungi le interfacce delle entità nel Data Access Layer e fai riferimento al livello di accesso ai dati con il progetto Entities.

Sono abituato a usare riferimenti non severi come hai descritto, uno strato superiore può fare riferimento a uno qualsiasi dei livelli inferiori. In un riferimento rigoroso, uno strato superiore dovrebbe fare riferimento solo al livello inferiore più vicino.

    
risposta data 09.11.2011 - 10:34
fonte
1

Solo un paio di suggerimenti:

  • Infrastruttura e accesso ai dati dovrebbero essere due livelli separati. Le loro preoccupazioni sono abbastanza diverse per quello.
  • Forse "l'archiviazione dell'utente attualmente connesso" è più adatta per la classe di infrastruttura, poiché questi dati si basano probabilmente su un sistema di autenticazione / autorizzazione dipendente dal sistema.
  • Le implementazioni del repository dovrebbero andare nel livello di accesso ai dati, ma i contratti di repository dovrebbero andare nel livello aziendale (poiché gli oggetti business sanno quali sono i requisiti di persistenza).
risposta data 10.10.2011 - 10:47
fonte
0

Nlayer design .net 4.0

Le interfacce del repository devono trovarsi nel livello del dominio aziendale (o) del dominio in modo da poter disporre di implementazioni di persistenza differenti rispetto al modello di dominio. Nota che l'interfaccia appartiene al client e non all'implementatore.

La logica dell'accesso ai dati potrebbe essere in infrastruttura poiché si occupa di tecnologie come EF o NHibernate. Tutto ciò che riguarda la tecnologia come il framework UI, il framework DB, le implementazioni del framework di logging potrebbe essere nel livello infrastruttura e potresti avere spazi di nome Infrastructure.Crosscutting e Infrastructure.Data.

    
risposta data 10.12.2011 - 20:28
fonte