LINQ vs Data Access Layer

Mi sono sempre insegnato a gestire qualsiasi codice di accesso ai dati in un 'livello' completamente separato dalla mia logica aziendale e dal mio codice UI. Questa è sempre stata una buona architettura per me e tutte le "regole" o le migliori pratiche che vedo riescono ancora a adattarsi a questo stile di codifica, in particolare il principio della responsabilità singola .

Per la maggior parte dei miei progetti domestici, userei il mio ORM che ho creato, che ho sempre pensato di creare open-source. Tuttavia da allora, LINQ è diventato disponibile, il che era molto simile al modo in cui il mio ORM funzionava (ma ... meglio).

Non c'è nulla che prima potessi fare con il mio ORM che ora non posso fare con LINQ (tranne i bit dell'integrazione REST). Quindi la mia domanda è; LINQ è il mio nuovo livello di accesso ai dati? Ho più bisogno di questo livello? Il mio BLL dovrebbe semplicemente parlare direttamente con LINQ? O questa cattiva pratica è ancora?

Modificare:

La domanda originale si riferiva a LINQ to Entities, ma ci sono molte risposte interessanti su LINQ to SQL. Quali sono i pensieri delle persone su entrambi? Ho capito che LINQ to SQL non può davvero sostituire un DAL, ma Entity Framework potrebbe?

Sebbene sia possibile inserire solo query LINQ nel BLL, ciò può comportare la duplicazione del codice. Vorrei ancora creare repository che saranno un wrapper per le query LINQ. Ciò separerà il codice del database dal codice BLL e sarà utile quando si decide di modificare il codice di accesso ai dati (ad es. Passare a Dapper o alle query precompilate).

Aiuterà anche con i test unitari , poiché i repository possono essere facilmente derisi.

Potresti avere ancora un DAL, solo che potrebbe usare LINQ to SQL invece di quello che avevi usato in precedenza. È così che lo faccio comunque. Non fare in modo che il BLL utilizzi direttamente LINQ to SQL per accedere ai dati.

Linq non riguarda l'accesso ai dati, puoi usare linq verso qualsiasi IEnumerable.

Hai provato a progettare la tua applicazione senza pensare inizialmente al database? Cioè, implementa la tua applicazione e usa una specie di repository. Quindi usi qualsiasi tecnica per implementare quei repository. In questo modo hai una soluzione totalmente disaccoppiata in cui puoi inserire qualsiasi livello di accesso ai dati desiderato.

In quel livello di accesso ai dati puoi usare il tuo ORM o puoi usare Linq a sql, non importa se il livello di accesso ai dati implementa i repository che hai definito.

A meno che non si desideri che il proprio "livello di logica aziendale" si occupi delle transazioni e delle prestazioni delle query, è comunque necessario un DAL.

LINQ rende la dichiarazione di query un processo in fase di progettazione (alias, controllato dal compilatore).

I provider di query LINQ (come LinqToSql e LinqToEntities) eseguono ancora la conversione di runtime di tali query dichiarate in testo sql. Quindi il DBMS esegue ancora l'interpretazione delle query di runtime, la generazione del piano di query di runtime, ecc.

Queste sono solo una piccola parte del DAL.