LINQ vs рівень доступу до даних

10

Я навчив себе завжди обробляти будь-який код доступу до даних в абсолютно окремому «шарі» до моєї бізнес-логіки та коду інтерфейсу користувача. Це завжди була для мене дуже хорошою архітектурою, і будь-які «правила» чи найкращі практики, які я бачу, все ще вдається вписатись у цей стиль кодування, особливо Принцип єдиної відповідальності .

Для більшості моїх домашніх проектів я використовував би власну створену ORM, яку я завжди мав намір робити з відкритим кодом. Однак з тих пір LINQ стала доступною, що було дуже схоже на те, як працював мій ORM (але ... краще).

Раніше я нічого не міг би зробити із власною ORM, що зараз не можу зробити з LINQ (крім бітів інтеграції REST). Отже, моє запитання; LINQ - це мій новий рівень доступу до даних? Чи потрібен мені цей шар взагалі більше? Чи повинен мій BLL просто поговорити з LINQ? Або це ще погана практика?

Редагувати:

Первісне питання стосувалося LINQ для Entities, але є багато цікавих відповідей щодо LINQ для SQL. Які думки народів щодо обох? Я знаю, ніж LINQ в SQL насправді не може замінити DAL, але чи може Entity Framework?

— Connell
джерело

7

Хоча ви можете просто помістити запити LINQ у свій BLL, це може призвести до дублювання коду. Я б все-таки створив сховища, які стануть обгорткою для запитів LINQ. Це відокремить код бази даних від коду BLL і стане корисним, коли ви вирішите змінити код доступу до даних (тобто перейти на Dapper або попередньо складені запити).

Це також допоможе при тестуванні одиниць , оскільки сховища можна легко глумати.

— Якуб Конецький
джерело

6

У вас ще може бути DAL, тільки він може використовувати LINQ для SQL замість того, що ви раніше використовували. Ось так я це все роблю. Не змушуйте BLL безпосередньо використовувати LINQ для SQL для доступу до даних.

— neeKo
джерело

Я погоджуюся, що LINQ до SQL - це лише мова запиту, яка може завадити вам написати багато сантехнічного коду. Він не інкапсулює доступ до даних у вашій програмі так, як повинен бути DAL.

— neontapir

Я справді мав на увазі LINQ на Entities. Я також використовую багато LINQ для об'єктів, але вважаю це діловою логікою. Я розумію різницю між Entities і LINQ в SQL, але я ніколи не використовував LINQ для SQL. Чи є різниці в синтаксисі?

— Коннелл

2

Linq не стосується доступу до даних, ви можете використовувати linkq до будь-якого IEnumerable.

Ви намагалися розробити додаток, не замислюючись про базу даних спочатку? Тобто реалізуйте свою програму та використовуйте якесь сховище. Тоді ви використовуєте будь-яку техніку для реалізації цих сховищ. Таким чином у вас є повністю розв'язане рішення, де ви можете підключати будь-який рівень доступу до даних, який ви хочете.

У цьому рівні доступу до даних ви можете використовувати свій власний ORM або ви можете використовувати Linq для sql, це не має значення, поки рівень доступу до даних реалізує визначені вами сховища.

— Томаш Янссон
джерело

1

Якщо ви не хочете, щоб ваш "рівень бізнес-логіки" вирішував транзакції та ефективність запитів, все ще існує потреба у DAL.

LINQ робить декларування запитів процесом проекту (часом, перевіреним компілятором).

Постачальники запитів LINQ (наприклад, LinqToSql та LinqToEntities) все ще виконують перетворення заявлених запитів у текст sql в процесі виконання. Тоді СУБД все ще виконує інтерпретацію запитів під час виконання, генерацію плану запитів під час виконання тощо.

Це лише невелика частина DAL.

— Емі Б
джерело