Non conosco progetti o tutorial specifici, mi spiace.

Ad ogni modo i concetti che stai cercando sono tutti indipendenti dalla tecnologia che usi. Il Repository pattern, se lo implementi in .NET, in .NET Core, in Java, in PHP, ecc. è sempre quello. Cambia la sintassi del linguaggio ma non è vincolato dallo stack tecnologico utilizzato. La stessa cosa vale anche per l'architettura dell'applicazione, non c'è una regola o un dogma da rispettare alla lettera, puoi trovare linee guida e standard ben collaudati con cui aiutarti ma poi la struttura la devi un po' modellare ai tuoi requisiti. In alcuni casi ci possono essere progetti dove l'applicazione di certi pattern potrebbero essere più di intralcio che di supporto.

Un progetto da cui potresti cominciare a farti un'idea di come viene strutturata un'applicazione "reale" la trovi qui https://github.com/dotnet-architecture/eShopOnWeb. Si tratta di un progetto ASP.NET Core, ma i concetti sono applicabili anche ad ASP.NET "classico".

Ciao, Marco.

---

Modificato da santoni1981 il 16 settembre 2021 14:10 -

Ciao JoeRuspante, interessante la tua risposta. Rispondo con le mie considerazioni per uno scambio di opinioni con te. Ti scrivo come la penso io, da "amante del codice ben strutturato", magari poi mi dai qualche spunto/consiglio interessante ed imparo qualcosa di nuovo.

Lavoro col repository pattern in alcuni progetti e, per come lo conosco io, non è corretto da un repository accedere a tabelle di altri repository, seppure logicamente collegati.

Hai ragione, il Repository pattern, a livello accademico, sarebbe corretto implementarlo come hai indicato tu, ovvero una classe Repository per ogni entità del modello. Però, io sono dell'idea che le regole ci sono anche per essere infrante se necessario: nel caso specifico descritto da Piero, forse avere un repository per le promozioni andrebbe a complicare il codice inutilmente (intendo per i suoi requisiti [che magari ho frainteso!]). Se stessimo discutendo dell'architettura di un e-shop come Amazon o eBay certamente avere una classe "PromozioniRepository" darebbe i suoi vantaggi, ma allora ci sarebbe bisogno di tanti altri attori (entità e repository) ed a quel punto dovremmo forse introdurre anche il pattern Unit of Work. Quindi mi chiedo, in un piccolo e-shop ha senso? Sicuramente non farebbe male fare le cose seguendo i dogmi, sono d'accordo, ma per ottenere quali vantaggi?

Diventa comodo quando sai già che dovrai avere basi dati disomogenee e/o sai che dovrai gestire più tipi di database, compresi quelli che magari non sono supportati da EntityFramework.

Non capisco cosa intendi, io il Repository pattern lo implemento anche con progetti che nascono con un db omogeneo.

Nella tua situazione credo sia più corretto lavorare col concetto dei servizi di business.
In pratica ti puoi fare una classe "ServizioDeiProdotti" che nel costruttore prende tutto quello che gli serve per lavorare:
- I repository dei prodotti e delle promozioni se lavori col repository pattern
- Il DbContext se lavori con EntityFramework

Sarà quindi nel servizio che implementerai il metodo "OttieniProdottiConPrezzo" che torna quello che ti serve.

Nel tuo controller utilizzerai direttamente il servizio di cui sopra per accedere al prodotto (passi sempre per i servizi di business, mai direttamente dai repository).

Sono d'accordo con te anche se non passerei il DbContext di Entity Framework.

Sinceramente se puoi lavorare con EntityFramework anzichè usare un repository è molto meglio. Il repository pattern è molto comodo in determinate situazioni ma per i progetti semplici è più il tempo che si spreca ad implementarlo che il vero vantaggio ottenuto

Su questa affermazione io non sono d'accordo (magari a torto). Non credo sia una buona scelta lavorare direttamente con EntityFramework, si tratta comunque di un e-shop anche se piccolo. Io credo che lavorare direttamente con EF può essere un buon suggerimento quando si vanno a sviluppare piccole utility che sai già che non evolveranno nel tempo o comunque resteranno semplici. Nel caso di un gestionale (o un e-shop come in questo caso) io opterei comunque per strutturare l'applicazione con un layer "Application" che contiene la logica di business ed un layer "Infrastructure" che contiene il codice infrastrutturale come l'accesso al db (con EF, Dapper o ADO.NET, Repository, che sia). Entrambi i due layer appena descritti li terrei separati dal layer "Presentation".

Cosa ne pensi a riguardo? Mi farebbe molto piacere conoscere la tua opinione.

Ciao.

Provo a rispondere alle tue considerazioni.

I pattern sono delle regole guida che servono per risolvere certe situazioni. In pratica ti dicono che se hai il problema X e lavori nel modo Y, il tuo prodotto sicuramente funzionerà.
Se devi usarli per poi infrangerli, non ha alcun senso.

D'accordissimo con te, hai pienamente ragione. Forse mi sono un po' espresso male, io per infrangere le regole mi riferivo al caso specifico di "accorpare" (per semplificare) al repository dei Prodotti anche il recupero del prezzo scontato. Concordo sul fatto però che poi c'è altro da tenere in considerazione ed alla fine avere anche il repository delle Promozioni (come dicevi tu) è una scelta vincente.

Uno dei vantaggi del repository pattern è proprio quello di poter cambiare facilmente la base dati nel tempo: cambi il repository e sei a posto. Se però alla tabella X accedi da diversi repository, poi devi andarli a cambiare tutti e perdi il vantaggio del repository.

Si, concordo.

Se però non hai queste necessità e stai iniziando un nuovo progetto, secondo me EntityFramework è già più che sufficiente. Se vogliamo possiamo vedere il DbSet<T> come un Repository<T> e il DbContext come il gestore delle unit of work.
E' un po' una forzatura, però in linea di massima non siamo poi così tanto lontani dalla realtà.

Continuo ad essere convito che separare i due layers (quello di business da quello dell'infrastruttura) sia la cosa migliore ma è solo una mia opinione personale . Per ora, anche in progetti piccoli, mi sono sempre trovato bene lavorando in questo modo.

Per quanto riguarda il caso di Piero, sicuramente abolirei il discorso del repository pattern: i costi superano i benefici.

Anche qui non mi trovo d'accordo, ma è comunque come sopra una mia opinione. Sia chiaro, non sto dicendo di usarlo per forza ma sono dell'idea che sia un'opzione il Repository pattern. Io penso che in un progetto con l'e-shop in questione eviterei di usare EF direnttamente nel layer di business. Magari "spreco" un po' di lavoro in più ma ho la sensazione di avere almeno un po' più di ordine (e penso anche qualche beneficio in termini di debug [unit test?!] manutenzioni ed evoluzioni future).

Come strutturare l'applicazione dipende dalla grandezza e/o dalle possibilità di espansione nel tempo. Se il progetto è piccolino e ci sono poche implementazioni previste, allora ti bastano 3 livelli: EF per la base dati, i servizi di business per le logiche applicative, quindi la UI.

Se invece il progetto è già grandino e/o è previsto evolva nel tempo, allora concordo che sia meglio pensare ad una struttura più importante, magari anche appoggiarsi al CQRS, fare progetti distinti per ogni layer applicativo qualora in futuro debba essere sostituito, ...

Senza conoscere il dominio esatto, però, è difficile suggerire la struttura ideale

"Sfondi una porta aperta." Parlare di architettura senza conoscere il dominio esatto è un po' come parlare del sesso degli angeli.

Ad ogni modo, ti ringrazio molto per la chiacchierata, è stato interessante e costruttivo scambiare due righe con te a riguardo.

flaviovb ha scritto:

Separerei i livelli in progetti separati innanzitutto a prescindere dal namespace. Se un domani hai bisogno di accedere al DL per referenziarlo in una webapi o in una console app che fa da task ad esempio non potrai farlo se integri tutto in una unica soluzione/progetto

Condivido quanto scrivi, lo trovo corretto. Inoltre, un altro vantaggio ad avere un DL separato, è quello di poter testare la logica di accesso ai dati (il DL) in modo indipendente (ad esempio con degli Unit Test).

---

Modificato da santoni1981 il 19 settembre 2021 16:12 -