LINQ vs Lapisan Akses Data

10

Saya selalu belajar sendiri untuk menangani kode akses data dalam 'lapisan' yang sepenuhnya terpisah dengan logika bisnis dan kode UI saya. Ini selalu menjadi arsitektur yang sangat baik bagi saya dan 'aturan' atau praktik terbaik yang saya lihat, masih berhasil menyesuaikan dengan gaya pengkodean ini, terutama Prinsip Tanggung Jawab Tunggal .

Untuk sebagian besar proyek rumah saya, saya akan menggunakan ORM saya sendiri yang saya buat, yang selalu saya maksudkan untuk membuat open-source. Namun sejak itu, LINQ menjadi tersedia, yang sangat mirip dengan cara kerja ORM saya (tapi .. lebih baik).

Tidak ada yang sebelumnya dapat saya lakukan dengan ORM saya sendiri yang sekarang tidak dapat saya lakukan dengan LINQ (kecuali bit dari integrasi REST). Jadi pertanyaan saya adalah; itu LINQ Lapisan Akses Data baru saya? Apakah saya perlu lapisan ini lagi? Haruskah BLL saya hanya berbicara langsung dengan LINQ? Atau masihkah praktik buruk ini?

Edit:

Pertanyaan aslinya mengacu pada LINQ ke Entitas, tetapi ada banyak jawaban menarik tentang LINQ ke SQL. Apa pendapat orang tentang keduanya? Saya mengumpulkan dari LINQ ke SQL tidak bisa benar-benar menggantikan DAL, tetapi bisakah Entity Framework?

— Connell
sumber

7

Meskipun Anda bisa menempatkan kueri LINQ di BLL Anda, ini dapat menyebabkan duplikasi kode. Saya masih akan membuat repositori yang akan menjadi pembungkus untuk permintaan LINQ. Ini akan memisahkan kode Database dari kode BLL dan akan berguna ketika Anda memutuskan untuk mengubah kode akses data Anda (mis. Pindah ke Dapper, atau ke kueri yang dikompilasi sebelumnya).

Ini juga akan membantu dengan pengujian unit , karena repositori dapat dengan mudah diejek.

— Jakub Konecki
sumber

6

Anda masih bisa memiliki DAL, hanya saja bisa menggunakan LINQ ke SQL daripada apa yang sebelumnya Anda gunakan. Begitulah cara saya melakukannya. Jangan membuat BLL Anda secara langsung menggunakan LINQ ke SQL untuk mengakses data.

— neeKo
sumber

Saya setuju, LINQ to SQL hanyalah bahasa query yang dapat mencegah Anda menulis banyak kode pipa ledeng. Itu tidak merangkum akses data dalam aplikasi Anda seperti seharusnya DAL.

— neontapir

Saya benar-benar merujuk ke LINQ untuk Entitas. Saya juga menggunakan banyak LINQ untuk Objects tetapi saya menganggap itu sebagai logika bisnis. Saya mengerti perbedaan di balik layar antara Entitas dan LINQ untuk SQL, tapi saya tidak pernah menggunakan LINQ untuk SQL. Apakah ada perbedaan dalam sintaksis?

— Connell

2

Linq bukan tentang akses data, Anda dapat menggunakan LINQ terhadap apa pun IEnumerable.

Sudahkah Anda mencoba merancang aplikasi Anda tanpa memikirkan database? Yaitu, terapkan aplikasi Anda dan gunakan semacam repositori. Kemudian Anda menggunakan teknik apa pun untuk menerapkan repositori tersebut. Dengan begitu Anda memiliki solusi yang benar-benar terpisah di mana Anda dapat plugin apa pun lapisan akses data yang Anda inginkan.

Dalam lapisan akses data Anda bisa menggunakan ORM Anda sendiri atau Anda bisa menggunakan Linq ke sql, itu tidak masalah asalkan lapisan akses data mengimplementasikan repositori yang telah Anda tetapkan.

— Tomas Jansson
sumber

1

Kecuali jika Anda ingin "lapisan logika bisnis" Anda untuk mengatasi transaksi dan kinerja permintaan, masih ada kebutuhan untuk DAL.

LINQ membuat deklarasi permintaan proses desain (alias, compiler diperiksa).

Penyedia query LINQ (seperti LinqToSql dan LinqToEntities) masih melakukan konversi run-time dari kueri yang dinyatakan ke teks sql. Kemudian DBMS masih melakukan interpretasi run-time query, pembuatan rencana run-time dll.

Ini hanya sebagian kecil dari DAL.

— Amy B
sumber