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.
