DbContext, DbSet и т. Д. В Dapper

Я работаю над реализацией всех данных с помощью dapper. Моя первая идея заключалась в реализации шаблона репозитория с использованием dapper. от: http://www.bradoncode.com/blog/2012/12/creating-data-repository-using-dapper.html DbContext, DbSet и т. Д. В Dapper

Затем я добавил выражение linq в dapper sqlbuilder для минимизации SQL, как в примере (динамический запрос). Так что я был в состоянии написать что-то вроде

sqlbuilder.Where(c=>c.Id == 1) or c.Id = myVar

А теперь я спрашиваю себя, если это было бы хорошей идеей, чтобы реализовать DbContext как и DbSet и выражения использовать Linq.

Вопрос не в том, чтобы реализовать полный dbset или dbcontext. Но просто что-то похожее (без всякой сложности).

Только DbContext, инициализирующий соединение и несколько DbSet, который запрашивает таблицы с использованием Dapper и реализацию iqueryable для «генерации» SQL на основе данного выражения ссылок с использованием dapper sqlbuilder.

После прочтения некоторых фрагментов кода и сопоставления с сущностью, я считаю, что это пустая трата времени, поскольку инфраструктура сущности уже делает это. Но с dapper у вас есть весь контроль над сгенерированным sql, и он всегда будет использовать один и тот же шаблон.

Прежде чем начать (чтобы тратить свое время), я хотел бы знать, хорошая ли это идея или нет.

Редактировать: много комментариев говорит, что SqlBuider не очень хорошо, тогда почему он доступен в проекте Dapper?

источник

2015-04-03 Madagaga

Если вы хотите, чтобы все функции Entity Framework, Ditch Dapper и использовали Entity Framework. Code-First делает вещи довольно легкими, и вам не придется беспокоиться о том, чтобы делать это самостоятельно. –

Вы не можете иметь это в обоих направлениях. EF и L2S медленны по какой-то причине, Dapper быстро по какой-то причине.Если вы сделаете Dapper в EF или L2S, он будет таким же медленным, потому что генераторы SQL просто не идеальны, и если вы не являетесь экспертом в разработке таких генераторов (что по внешнему виду вещей вы не знаете) не собираются никуда даже приближаться к тем, что делают L2S и EF, поэтому ваш генератор, вероятно, произведет результаты WORSE, чем EF или L2S. Помните, что для создания хорошего SQL намного больше, чем простого перевода. –

Благодарю вас за ответ. Это всего лишь вопрос, и я не претендую на то, чтобы быть таким же хорошим, как дизайнеры/разработчики EF. Даже если мой вопрос глупо, хороший ответ может помочь не эксперту, как я. – Madagaga

Лично я бы сказал, что это то, что находится вне ядра того, что пытается предложить библиотека dapper. В этой идее есть заслуга, но я беспокоюсь, что к тому моменту, когда вы это сделали, yoouve в основном просто переработал LINQ-to-SQL. Есть более простой способ сделать это: вы просто используете LINQ-to-SQL. Обычно Dapper заполняет модели L2S - то есть по существу, как мы (авторы dapper) использовали его (и продолжаем использовать его) против нашей ранее существующей кодовой базы L2S. Он также будет похож на EF и т. Д.

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

источник

2015-04-03 14:51:46

Благодарим вас за ответ и советуем. Первоначальная идея состояла в том, чтобы иметь что-то вроде SQLinq.Dapper на codeplex, но с выражением лямбда. Также как использование dbsets. Я подумаю об этом и попробую ORM. Снова благодарим за все ваши ответы (не только за последние). – Madagaga

Я нашел что-то похожее на мою идею. https://code.google.com/p/dapper-dot-net/issues/detail?id=76. Поэтому первоначальный вопрос был неправильным. Хороший термин - поставщик Linq для dapper. – Madagaga

http://iqtoolkit.codeplex.com/ – Madagaga

Ключевой особенностью Dapper является производительность.

Dapper был создан для быстрого отображения результатов с простого SQL на объекты. И определенно не для того, чтобы позволить разработчикам избежать написания SQL. Возможно, неплохо использовать SQL-конструктор с Dapper. И еще хуже идея заключается в осуществлении отслеживания изменений. Просто используйте Entity Framework или другую полноразмерную ORM, если вам нужны такие функции.

источник

2015-04-03 14:28:44 Dissimilis

Я понимаю вашу точку зрения. Идея состоит не в том, чтобы использовать все функции EF, а просто для добавления функции linq в sql. Я не знаю, как объяснить свою идею. Реальная цель - иметь гибкость методов Iqueryable и поддерживать перфомансы dapper. Для моего проекта им нужен sql-конструктор без написания строки, поэтому выражение linq было для меня лучшим способом, нет? – Madagaga

Вы не можете сохранить производительность Dapper :) IQueryable - это ленивая оценка, и в этом случае это означает ухудшение производительности. Вам действительно нужна такая высокая производительность? Вы пробовали более подходящие альтернативы, такие как Subsonic ORM? – Dissimilis

Мы говорим не о том же. Часть iqueryable или ienumerable, которая мне нужна, - это только синтаксис запроса не всех других механизмов. Это просто «как» из-за способа написания запросов. Я не нуждаюсь в магазине отслеживания отслеживания изменений и т. Д. Просто имея возможность писать что-то вроде dbset .where (c => c.foo == "bar") генерирует хороший SQL-код с dapper и возвращает ienumerable из T. Это была моя идея. – Madagaga

DbContext, DbSet и т. Д. В Dapper

ответ

Смежные вопросы