Вы помещаете запросы Linq2SQL повсеместно или в специализированных классах DAL?

Я полностью перенес все свои вызовы LinqToSQL в единственный DAL. Мой Веб-сайт и Бизнес-Слои не знают о платформе персистентности, которую я использую. Таким образом, если LinqToSql действительно умирает или если я решаю, что хочу использовать совершенно новую платформу, я не должен выслеживать все места, я выполнил вызовы DB.

Это также помогает с возможностью многократного использования. Я могу использовать тот же Бизнес или DAL в других проектах, которые используют ту же базу данных.

LINQ является конструкцией языка. Все, чего требуется, - то, что Ваш DAL выставляет Ваши объекты как IEnumerable или IQueryable, и можно использовать LINQ против него. Ваш DAL мог быть основан на LINQ2SQL или LINQ2Entities или Вашем собственном коде - пока он выставляет Ваши объекты правильно. Вы получаете некоторые преимущества, как задержанное выполнение запросов, если Вы используете LINQ2SQL, но это не строго необходимо. Я не вижу никакой смысл в предотвращении использования LINQ за пределами DAL. Если я хочу заменить DAL чем-то еще не основанным на LINQ2SQL, я могу. Пока я поддерживаю интерфейсы, что основанный на LINQ код ожидает, что я в порядке.

Править: Нижняя строка для меня - то, что, пока они не поражают DAL, они не запросы LINQ2SQL, они - просто LINQ. LINQ не собирается исчезать из языка, если он не заменяется чем-то лучше. Вещь, которая делает это LINQ2SQL, состоит в том, что DAL реализован с LINQ2SQL. Остальная часть моего кода не знает (или уход), который это так. Это мог быть LINQ2Objects или LINQ2Entities или...

Помещение всех моих запросов Linq2SQL в отдельный класс помогает заменить его "насмешкой/тупиком" при тестировании бизнес-объектов, которые получают доступ к нему.

Или я неправильно?

Если Вы думаете о своих запросах LINQ, как являющихся запросами LINQ2SQL Вы немного упущение сути.

У Вас есть запросы LINQ. Ваш бизнес-слой получает доступ к слою данных путем создания запросов LINQ на слое данных (datacontext). LINQ2SQL является компонентом, который позволяет запросам LINQ получать доступ к SQL Server.

Это - серьезное упрощение, но общая точка - то, если Вы скрываете весь свой LINQ от бизнес-слоя Ваш не действительно польза от ее причины существовать.

Если LINQ2SQL не позволяет Вам абстрагировать свою схему DB до градуса, который Вы любите затем, необходимо рассмотреть использование Платформы Объекта вместо этого.

• Я использую внешнее отображение.
• Доменные классы находятся в отдельном блоке.
• datacontext находится в блоке помощников.
• У меня есть много xml отображающиеся файлы

Когда мне нужен доступ к базе данных, я инстанцирую Помощников. DataContext, со строкой подключения (который база данных) и отображающийся файл (который таблицы отобразиться).

Это сохраняет хорошее разделение проблем.

Я лично создаю "базовый" запрос и выставляю IQueryable.

В моих бизнес-объектах мне нравится возвращать конкретные результаты, поэтому я обычно делаю метод стиля QueryByExpression только внутренним, а затем создаю заглушки методов, в которые я могу передать свои критерии, а в методе, который я обрабатываю, получаю результатов из базы данных, и возвращать IEnumerable результатов, не подвергая остальную часть приложения необходимости контекста или чего-то еще.

Но, как и многие из упомянутых выше людей, я должен согласиться - раскрывая ваш IQueryable для вашего кода не является ужасным, он просто делает его более привязанным к вашему материалу Linq2Sql.

Если нет ' Не думая о создании бизнес-объектов, которые предоставляют методы, но не предоставляют тип IQueryable, я считаю, что это лучше, но более утомительно устанавливать и настраивать бизнес-объект. Я чувствую, что это также легче проверить, но это только я. Также сделайте так, чтобы его можно было повторно использовать, и если вы исправите ошибку, она не будет существовать в 30 различных местах вашего кода 2 года спустя.

Только мои 2 цента.

Я бы не стал обязательно создавать отдельные бизнес-объекты просто потому, что это суть LINQ2SQL, и вы будете воссоздавать многое из того, что делает LINQ2SQL таким замечательным.

Однако я бы рекомендовал создать библиотеку классов со статическими классами с вашим кодом L2SQL в ней. Это дает вам возможность заменять отдельные сборки для изменения бизнес-логики. Кроме того, если у вас есть дополнительные методы для доступа к данным, ваши статические классы - хорошее место для этой логики.

] Я использовал Linq2SQL в DAL DLL. Мне нравится разделение проблем плюс любые другие сайты или приложения, нуждающиеся в доступе к той же самой базе данных, вы можете повторно использовать довольно много кода из вашей DLL. Так что все Linq2SQL хранится в этой DAL. Теперь для самого Linq я использую это и в моем сервисе, и в презентационном слое в зависимости от необходимости.[

]Linq2SQL DLL layout [

]Creating the mapping .dbml file to map SQL table.columns to a Linq Catalog (SqlRepository)[

]Wrote sql repository classes, которые соответствуют классу сервисного слоя и используют соответствующий класс Linq Catalog. [

]Добавлены интерфейсы для каждого класса sql репозитория, чтобы сервисный уровень работал непосредственно с интерфейсом[

]Написаны бизнес-модели, которые классы sql репозитория передаются туда и обратно с сервисным уровнем. [

В моем последнем проекте используется ASP.NET MVC фреймворк и LINQ-to-SQL. По этой причине я сильно завишу от паттерна Репозитария для моего уровня данных. Так как это мой первый проект LINQ-to-SQL, схема базы данных представлена в рамках одного класса DataContext. Поскольку появляются более поздние проекты, я могу вырезать общие DataContexts для повторного использования.

Я создаю интерфейс, который содержит все сигнатуры, которые я планирую реализовать для конкретного репозитория, который обычно представляет собой один сложный объект. На основе этого интерфейса я реализую два класса: один для производства, другой для тестирования. Все мои запросы LINQ-SQL хранятся в классах репозитория. В коде контроллера я получаю доступ к репозиториям для своих методов доступа к данным. Я не включаю запросы в мои представления; я использую пользовательские классы моделей представлений, которые заполняются в контроллерах с помощью репозиторных методов.