Come posso interrogare tabelle incrociate con Pattern di deposito?

Nella mia applicazione asp.net mvc 3, sto utilizzando il modello di repository. Ho 3 entità, società, paese, città. Ognuno di loro ha il proprio repository. Le entità estere hanno fondato le chiavi esterne di Country e FoundedCity. Ora in una vista, voglio mostrare i dettagli dell'azienda. In questa vista voglio visualizzare i dettagli della società, nonché il nome di FoundedCountry e il nome di FoundedCity. A mio parere, devo gestirlo con una specie di query JOIN. Ma sono bloccato su come ottenere questo risultato in un modello di repository. Come posso gestire questo JOIN in pattern di repository?Come posso interrogare tabelle incrociate con Pattern di deposito?

Grazie.

fonte

2012-04-23 SherleyDev

Il repository deve avere un'interfaccia basata su attività. Ciò significa che ORM, join ecc. Si trovano all'interno del repository. L'app vede solo un'interfaccia che restituisce un oggetto che può utilizzare.

Ciò significa che non si crea un repository attorno a un tavolo (praticamente non si risolve lo scopo). Nel tuo scenario ti suggerisco di avere (almeno) 2 repository: uno gestirà tutto ciò che riguarda l'aggiornamento del modello e l'altro servirà solo le letture (query).

Ciò significa che il repository di query restituirà solo i dati desiderati (in pratica restituisce i bit del modello di visualizzazione). Naturalmente, le tabelle e i join effettivi rappresentano un dettaglio di implementazione del repository.

fonte

2012-04-24 10:06:48 MikeSW

"Ciò significa che non si crea un repository attorno a una tabella (sconfigge praticamente lo scopo). " Per quanto ne so, devo creare un repository per ogni entità. Dal tuo commento, penso di dover aggiungere un altro repository che gestirà query complesse. Destra? – SherleyDev

No :). Non è necessario creare un repository per ciascuna entità. Il repository nasconde praticamente tutto il database correlato dal resto dell'app. All'interno del repository potresti usare entità, EF o Nibernate, non importa. Il repositoryu usa internamente l'orm, nel tuo caso le entità e restituisce gli oggetti che l'app comprende. Le entità stesse sono già un'astrazione utilizzata dal repository. – MikeSW

Nel seguente tutorial si dice "In questo tutorial implementerai una classe di repository per ogni tipo di entità." Lo stavo seguendo. http: //www.asp.net/mvc/tutorial/get-started-with-ef-using-mvc/implementazione-the-repository-and-unit-of-work-patterns-in-un-asp-net-mvc-application – SherleyDev

Non costruire il modello di repository in un modo che impedisce i join! Questo di solito significa utilizzare lo stesso contesto ORM (DataContext/ObjectContext) per tutte le istanze associate alla richiesta HTTP corrente.

Ritengo che sia un anti-pattern per avere un IRepository generico perché l'accesso al database è raramente limitato a un singolo tipo di entità allo stesso tempo.

Si può considerare DataContext/ObjectContext come un repository di per sé.

Un ultimo consiglio: se non si sa a cosa serve un'astrazione del repository, non utilizzarne uno.

fonte

2012-04-23 22:32:36 usr

Non sono d'accordo con una cosa: che il contesto dati deve essere considerato come un repository. Mentre la DC astrae l'accesso db e sql, è ancora legato a un rdbms e IMO è un'astrazione che perde nel migliore dei casi. – MikeSW

Se un ORM è un'astrazione che perde, in che modo perde un repository personalizzato? È un setaccio. Allo stesso tempo ti impedisce di accedere a tutta la potenza dell'ORM (che è la natura di un'astrazione). – usr

Un repository correttamente progettato non perde perché non espone dettagli di implementazione come un ORM. Il repository sfrutta tutta la potenza dell'ORM, è il suo lavoro, non è compito del resto dell'app conoscere o utilizzare l'orm. Si prega di consultare questo post http://www.sapiensworks.com/blog/post/2012/04/15/The-Repository-Pattern-Vs-ORM.aspx – MikeSW

Come posso interrogare tabelle incrociate con Pattern di deposito?

risposta

Problemi correlati