ORM - специфично для SQL Server 2008+ для .NET

Question

Существует ли ORM , привязанный к MS SQL 2008+, генерирующий код .NET, который использует преимущества специфических функций MS SQL?

Меня особенно интересуют 2 функции:

(1) выборка группы записей по их ключу, который не будет сопоставлен с запросом "выбрать в".
-это может быть достигнуто с помощью OPENXML в 2005+ или с помощью Табличные параметры в 2008 + + 1013 *

(2) вставка более одной записи с одним запросом к БД (это похоже на, но не то же самое, что Bulk-Insert). Например:

Customer[] customers = CreateSomeCostomers();  
dataManager.Save(customers);

Таким образом, связанный с SQL код готовится на клиенте, а затем полностью отправляется на сервер SQL.

Кстати, о хранимых процедурах не может быть и речи.

Я был бы рад, если бы вы, стекировщики, посоветовали мне.

Спасибо!

Обновление:

Я ищу complete решение, а не расширяемую среду / продукт, который я мог бы настроить в соответствии со своими потребностями. Так что настраивая NHibernate / linq2sql / etc. написав собственный код, реализация не соответствует моим потребностям.

<ч />

Несколько слов о принятом ответе.

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

Я понимаю, что @Ryk, указывая на Fluent NHibrenate, считает, что такое решение действительно существует, и это вопрос конфигурации. Я посмотрел на исходный код NHibernate и Fluent NHibernate, и я не нашел ничего, что поддерживает функции, которые я ищу. Например, я не смог найти ключевое слово OPENXML или sp_xml_preparedocument в обоих исходных кодах. Так что, может быть, я что-то упустил, но я так не думаю. Поскольку награда ограничена по времени, я не могу провести более глубокое расследование в ФН или НХ. Я все еще думаю, что эти функции там не поддерживаются.

Итак, принятый ответ, насколько я понимаю, что такого нет. Наиболее общий ответ, утверждающий, что это ответ @Cade Roux.

Я благодарю всех вас за участие. Ура!

Answer 1

К сожалению, нет.Microsoft решила выйти на мультиплатформенную линию с Entity Framework.Хотя было бы неплохо, если бы они построили что-то вокруг SQL Server и оставили другие БД для соответствующих поставщиков БД или сторонних картографов ИЛИ.

Answer 2

Я понимаю, что этот ответ приходит с некоторым опозданием (хотя может быть полезным для других, видящих его).По причинам, указанным здесь, а также для получения надлежащего управления исходным кодом БД в процессе, у нас есть собственный картограф, который доступен как проект с открытым исходным кодом: bsn ModuleStore

Этот набор инструментов непройти весь путь, который делают ORM, такие как nHibernate или Entity Framework, и для этого требуется еще немного кодирования.Тем не менее, он следует «старому доброму» подходу с SP для всего доступа к данным (не спорьте, пожалуйста, и у динамического, и у статического кода БД есть свои плюсы и минусы).Следствием этого является то, что запросы должны кодироваться вручную в SQL, что дает вам полный контроль над кодом, выполняемым на сервере БД.

Что касается некоторых преимуществ, вы получаете полное двунаправленное сопоставление сущностей (да, используя TVPс эффективным пользовательским считывателем данных, который «создает потоки» объектов вместо создания DataTable в памяти, как в большинстве примеров с TVP).Он также поддерживает SP, возвращающие несколько наборов результатов, и, наконец, что не менее важно, обеспечивает полностью интегрированную и достаточно расширяемую поддержку модульности базы данных, управления версиями (на уровне исходного кода для правильной интеграции с вашим SCM) и проверки целостности (сравнивая объекты, присутствующие в БДпротив исходных файлов).

Answer 3

Nhibernate - это единственный вариант, кроме написания собственного уровня доступа к данным, вы можете легко расширить Nhibernate для использования нового | специального | специфического синтаксиса SQL.

Answer 4

Да, я верю, что Свободный NHibernate будет делать то, что вы хотите. Требуется немного настроить, не слишком сложно, но как только он заработает, это удовольствие.

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

Основная идея заключается в том, что вы создаете классы сущностей и классы сопоставления, которые будут сопоставлять ваши объекты базы данных с объектами c #. Оттуда вы просто заполняете объект или список объектов и делаете Object.Update () или Object.Delete () или Object.Get () и т. Д. Уже встроенные, вам не нужно идти и подключать их. Вы всегда можете переопределить его, если хотите. Это очень гибкий.

Answer 5

Если вы хотите использовать функции SQL Server, то черный ящик ORM не собирается обслуживать это.

Если вы хотите получить максимальную отдачу от выбранной вами базы данных (любой базы данных), вы будете более тесно связаны, и поэтому вам лучше с генерацией кода для (генерации как хранимых процедур, так и) вашего слоя отображения вместо этого вставной ORM.