LINQ vs Livello di accesso ai dati

Naviga le tue risposte
10

Mi sono sempre insegnato a gestire qualsiasi codice di accesso ai dati in un "livello" completamente separato alla mia logica aziendale e al codice dell'interfaccia utente. Questa è sempre stata un'architettura molto buona per me e tutte le "regole" o le migliori pratiche che vedo, riescono ancora a inserirsi in questo stile di codifica, in particolare Principio di responsabilità singola .

Per la maggior parte dei miei progetti a casa, userei il mio ORM che ho creato, che ho sempre voluto rendere 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 potrei fare in precedenza con il mio ORM che ora non riesco a fare con LINQ (eccetto i bit dell'integrazione REST). Quindi la mia domanda è; LINQ è il mio nuovo Data Access Layer? Ho ancora bisogno di questo livello? La mia BLL dovrebbe parlare direttamente con LINQ? O è ancora questa cattiva pratica?

Modifica

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? Raccolgo che LINQ to SQL non può davvero sostituire un DAL, ma potrebbe Entity Framework?

    
posta Connell 01.11.2011 - 17:59
fonte

4 risposte

7

Sebbene sia possibile inserire query LINQ nel BLL, ciò potrebbe causare la duplicazione del codice. Creerei comunque repository che saranno un wrapper per le query LINQ. separerà il codice del database dal codice BLL e sarà utile quando deciderai di modificare il tuo codice di accesso ai dati (ad esempio, passa a Dapper o alle query precompilate).

Aiuterà anche con i test delle unità , in quanto i repository possono essere facilmente derisi.

    
risposta data 01.11.2011 - 18:07
fonte
6

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

    
risposta data 01.11.2011 - 18:07
fonte
2

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

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

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

    
risposta data 01.11.2011 - 18:10
fonte
1

Se non vuoi che il tuo "livello logico aziendale" indirizzi le transazioni e le prestazioni delle query, è ancora necessario un DAL.

LINQ rende la dichiarazione della query un processo in fase di progettazione (noto anche come compilatore controllato).

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

Queste sono solo una piccola parte del DAL.

    
risposta data 01.11.2011 - 19:17
fonte

Leggi altre domande sui tag

Capacità di pensiero per essere un buon programmatore [chiuso] Determinazione della giusta quantità di documentazione