Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

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