LINQ - в какой слой обычно попадает LINQ, DAL?

Question

просто хотел собрать разные идеи и перспективы относительно того, в какой слой (и почему) должен попасть LINQ?

Answer 1

LINQ = встроенные языковые запросы. Это расширение запроса, которое позволяет запрашивать что угодно, от баз данных до списков / коллекций и XML. Язык запросов полезен на любом слое.

Однако многие люди называют LINQ to SQL просто «LINQ». В этом контексте комбинированный BLL / DAL имеет смысл, когда вы используете L2S, и именно там вы делаете запросы LINQ к вашей базе данных. Это, конечно, не исключает выполнения последующих запросов к результатам тех же самых запросов в новых (Linq для объектов) запросах на более высоких уровнях ...

Answer 2

это зависит от того, что вы хотите сделать с linq. при использовании linq2sql я рекомендую DAL, но Linq - это больше, чем просто доступ к базе данных. Вы можете использовать его для управления списками, множественными бизнес-объектами и т. д. Сам Linq может быть полезен в любом приложении.

Answer 3

Я считаю, что ваш производный от DataContext объект относится к самому вашему уровню DAL, а LINQ - просто очень гибкий интерфейс к нему. Поэтому я использую запросы LINQ непосредственно на бизнес-уровне.

Answer 4

Я думаю, что если вы делаете Linq to Sql, вы всегда должны делать это в своем DAL. Однако, если вы делаете Linq to Objects, где вы просто фильтруете, играя с другим объектом, вы можете сделать это, слой BL.

Answer 5

Оба. DataContext - это DAL, и при использовании дизайнера автоматически генерируемые частичные классы, которые отображаются на объекты SQL (таблицы, представления), могут считаться частью вашего бизнес-уровня. Я реализую частичные классы, которые реализуют некоторые из частичных методов для обеспечения проверки и безопасности по мере необходимости. Некоторые бизнес-правила не отображаются непосредственно на объекты БД и обрабатываются с помощью других классов.

Answer 6

Я думаю, что смысл Linq в том, что он заменяет ваш DAL.

Эквивалентом вашего старого DAL является весь автоматически сгенерированный код в файлах DBML + все, что не может добавить Linq.

Answer 7

Это зависит от архитектуры вашего приложения и имеет огромное значение, насколько модель представления соответствует модели данных. Я согласен с тем, чтобы отделить операции бизнес-логики от объектов данных и методов доступа, созданных LINQ. Я также склоняюсь к тому, чтобы обернуть все операции уровня данных внутри класса менеджера, чтобы сделать контекст данных внутренним классом.

Answer 8

Я использую linq в традиционном «слое доступа к данным» или в «объектах доступа к данным». Это обеспечивает модульность кода, продвигает код данных в одном месте (по сравнению с вырезанием и вставкой одного и того же кода в нескольких разных местах) и позволяет относительно легко разрабатывать другой интерфейс.

Answer 9

Я думаю, что LINQ должен быть очень низкого уровня (DAL), и я думаю, что он должен быть заключен в BLL.

Я знаю, что многие люди любят использовать частичную доступность моделей, которые генерирует LINQ to SQL, но я думаю, что у вас должно быть четкое разделение интересов (посмотрите, что я там делал?). Я думаю, что если вы собираетесь использовать бизнес-логику, ее необходимо полностью отделить от логики доступа к данным.

Я думаю, что это усложняет тот факт, что вы можете продолжать цепочку этих методов расширения LINQ везде, где у вас есть строка с использованием System.Linq в вашем коде. Опять же, хотя я думаю, что LINQ относится к определению и должен быть на самом низком уровне. Это также значительно упрощает TDD / модульное тестирование, когда вы включаете использование LINQ в BLL.