Come si estrae il codice di persistenza quando si utilizza LINQ to SQL?

Question

Amo LINQ to SQL ma mi ha infastidito il fatto che, nell'utilizzarlo, il mio codice repository è stato generato dal framework LINQ in SQL e quindi strettamente accoppiato a un database SQL Server.

Alcuni di voi utilizzano LINQ in SQL in modo astratto, in modo approssimativo e, in tal caso, in che modo si è avvicinato al problema di mantenere indipendente la propria banca dati di codice?

Answer 1

Per me stesso; Sono contento di riutilizzare il modello a oggetti che LINQ/dbml genera, poiché in realtà gli attributi non mi fanno male, e qualsiasi altra implementazione potrebbe fornire un modello abbastanza simile - ma non utilizzo il mio contesto dati fuori dal DAL. Così ho qualcosa di simile:

• IFooRepository - definisce le modalità disponibili utilizzando sia gli oggetti DBML generati e alcune classi di modelli POCO
• FooRepository - l'implementazione che conosce il contesto dati

mio i metodi di repository non espongono concetti LINQ come IQueryable<T> e Expression<...>, poiché sono leaky abstractions; altre implementazioni funzioneranno in modo diverso (EF supporta diversi aspetti di entrambi, ad esempio).

Inoltre, ho utilizzato per contrassegnare la maggior parte delle proprietà di associazione come interne e usarle solo durante le interrogazioni DAL (non tanto durante il lavoro di OO).

Posso mappare su POCO puri, ma non vedo il vantaggio. Ho altre riflessioni su questo qui: Pragmatic LINQ.

Answer 2

È possibile utilizzare un approccio simile a quello utilizzato in NerdsDinner. Questo progetto utilizza il dat come contesto come gateway per il database e crea un repository attorno ad esso.

Questo tipo di modello di repository aggiunge alcune condizioni, filtri, comando di ordinamento ... ecc. Secondo il metodo chiamato e restituisce un IQuerable al chiamante lasciando la porta aperta per ulteriori modifiche.

In realtà si esegue quasi allo stesso modo quando si crea un repository attorno a una NHibernate ISession.

Se si è deciso di sostituire LinqtoSql con NHibernate, ad esempio, è sufficiente eseguire una query su una sessione Linq all'interno del repository anziché su quello datacontext. Naturalmente è necessario anche se per completare le classi parziali con le proprietà, che LinqtoSql aggiunge automaticamente.

Answer 3

Mouk sopra menziona il modello repository nel NerdsDinner, c'è anche un tutorial di come impostare rapidamente qui:

http://www.asp.net/learn/mvc/tutorial-10-cs.aspx

Questo un po 'di buona serie di tutorial che sono stati rilasciati prima della NerdsDinner. Il concetto qui può essere impostato anche in un'app di moduli web asp.net tradizionale.

Inoltre, vi suggerirei di usare LINQ to Entities (più recente, e più il supporto per altri DB), invece, alcuni principi fondamentali su che sono qui: http://www.asp.net/learn/mvc/tutorial-16-cs.aspx

Answer 4

Hey nathan, buona domanda.

Come altri hanno già detto, la cosa migliore da fare è astrarre tutti i metodi GET/WRITE e nascondere completamente DataContext dalla tua Business Logic.

Il mio approccio a questo è stato quello di scrivere un DAL con una serie di metodi generici che utilizzano la riflessione per fare tutto ciò che è necessario.

In questi casi, una volta che il metodo riceve un oggetto, ad esempio "Prodotto", può fare tutto ciò che vuole internamente indipendente dalla vostra tecnologia ORM/Data Access. Se vuoi, potresti letteralmente scrivere una stringa SQL basata su pochi parametri e riflessi dell'oggetto.

TUTTAVIA, fare questo da solo non ti elimina completamente da LINQ a SQL.

Il problema sono davvero le entità stesse. Anche se si astragga il metodo per recuperare i dati, si continueranno a utilizzare tali Entità fino alla logica aziendale.

Mi sembra, al momento, questo è solo qualcosa con cui sono pronto a convivere, perché riscrivere le mie Entità sconnesse sembra un ponte che non sono ancora pronto ad attraversare, solo perché sembra un molti lavori non necessari ...

Sarei molto interessato a vedere come gli altri affrontano questo però.

evviva!