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

Question

Я всегда вставлял свои запросы Linq2SQL повсюду, почти в каждый класс повсюду.

Мне бы хотелось узнать, какова ваша стратегия относительно того, куда помещать ваши запросы Linq2SQL?

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

Я думаю, что мне нужно изменить свою стратегию для запросов Linq2SQL и сохранить их в отдельных классах DataLayer. Я считаю, что это необходимо, если я хочу эффективно использовать TDD и соблюдать принцип внедрения зависимостей и принципы Solid ..

Answer 1

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

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

Answer 2

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

РЕДАКТИРОВАТЬ : Суть в том, что до тех пор, пока они не достигнут DAL, они не являются запросами LINQ2SQL, а просто LINQ. LINQ не исчезнет из языка, если он не будет заменен чем-то лучшим. Особенностью LINQ2SQL является то, что DAL реализован с помощью LINQ2SQL. Остальная часть моего кода не знает (или не заботится), что это так. Это может быть LINQ2Objects или LINQ2Entities или ...

Answer 3

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

Или я не прав?

Answer 4

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

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

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

Если LINQ2SQL не позволяет вам абстрагировать вашу схему БД в той степени, в которой вам нравится, вам следует рассмотреть возможность использования Entity Framework вместо этого.

Answer 5

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

Компоновка DLL Linq2SQL

Создание файла сопоставления .dbml для сопоставления таблиц SQL table.columns с каталогом Linq (SqlRepository)

Написал классы хранилища sql, которые соответствуют классу уровня Service и используют соответствующий класс Linq Catalog.

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

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

Answer 6

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

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

Answer 7

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

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

Однако я бы согласился с Флорианом, если ваши потребности немного сложнее, и вы не против создать свои собственные отображения.

Answer 8

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

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

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

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

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

Answer 9

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

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

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