Как вы абстрагируете свой код персистентности при использовании LINQ to SQL?

Question

Мне нравится LINQ to SQL, но меня беспокоит, что при его использовании мой код репозитория генерируется инфраструктурой LINQ to SQL и, следовательно, тесно связан с базой данных SQL Server.

Кто-нибудь из вас использует LINQ to SQL в абстрактной, слабосвязанной манере и если да, то как вы подошли к проблеме сохранения независимости кода от базы данных?

Answer 1

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

• IFooRepository - определяет методы, доступные как с использованием сгенерированных объектов dbml, так и некоторых классов модели POCO
• FooRepository - реализация, которая знает о контексте данных

Мои методы репозитория не предоставляют такие понятия LINQ, как IQueryable<T> и Expression<...>, поскольку они являются неплотными абстракциями ; другие реализации будут работать по-разному (например, EF поддерживает разные аспекты обоих).

Далее - я стал отмечать большинство свойств ассоциации как внутренние и использовать их только во время запросов DAL (не так много во время работы OO).

Я мог бы сопоставить с чистыми POCO, но я не вижу выгоды. У меня есть еще несколько мыслей по этому поводу здесь: Прагматичный LINQ .

Answer 2

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

Этот тип шаблона хранилища добавляет некоторые условия, фильтры, команду сортировки и т. Д. В соответствии с вызываемым методом, а затем возвращает вызывающему IQuerable, оставляя дверь открытой для дальнейших изменений.

На самом деле вы делаете почти так же, когда создаете хранилище вокруг NHibernate ISession.

Если вы решили заменить LinqtoSql, например, на NHibernate, вам нужно просто запросить сеанс Linq внутри своего хранилища вместо текстового. Конечно, вам понадобится дополнить ваши частичные классы свойствами, которые LinqtoSql добавляет автоматически.

Answer 3

Эй, Натан, хороший вопрос.

Как уже говорили другие, лучше всего абстрагировать все ваши методы GET / WRITE и полностью скрыть DataContext от вашей бизнес-логики.

Мой подход к этому заключался в написании DAL с набором универсальных методов, которые используют рефлексию, чтобы делать то, что необходимо.

В этих случаях, когда метод получает объект, скажем «Продукт», он может делать все, что ему угодно, независимо от вашей технологии ORM / Data Access. Если хотите, можете буквально написать строку SQL на основе нескольких параметров и отражения объекта.

ОДНАКО , выполнение этого в одиночку не полностью выведет вас из LINQ в SQL.

Проблема действительно в самих сущностях. Даже если вы абстрагируете метод извлечения данных, вы все равно будете использовать эти Entites всю свою бизнес-логику.

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

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

ура!

Answer 4

Mouk выше упоминает шаблон хранилища в NerdsDinner, здесь также есть руководство по быстрой настройке:

http://www.asp.net/learn/mvc/tutorial-10-cs.aspx

Это хорошая небольшая серия руководств, которые были выпущены до NerdsDinner. Концепцию здесь можно настроить и в традиционном приложении для веб-форм asp.net.

Кроме того, я бы предложил вместо этого использовать Linq To Entities (более новые и более поддерживающие другие БД), некоторые основные сведения о которых приведены здесь: http://www.asp.net/learn/mvc/tutorial-16-cs.aspx