LINQ - на какой уровень обычно должен попадать LINQ, DAL?

Question

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

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

Answer 9

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

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