BLToolkit альтернативный объект сопоставления, который поддерживает хранимые процедуры

Question

Я не слишком большой поклонник прямых сопоставителей сущностей, потому что я все еще думаю, что запросы SQL быстрее и лучше всего оптимизируются, когда пишутся вручную для базы данных и для нее (с использованием правильных объединений, группировок, индексов и т. Д.).

В моем текущем проекте я решил попробовать BLToolkit, и я очень доволен его оберткой вокруг Ado.net и скоростью, поэтому я запрашиваю базу данных и получаю сильные объекты типа C #.Я также написал T4, который генерирует помощники хранимых процедур , поэтому мне не нужно использовать магические строки при вызове хранимых процедур, поэтому все мои вызовы используют строгие типы для параметров.

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

Даунсайд

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

Вопрос

Какие альтернативы мнедолжны BLToolkit, которые:

• поддерживают использование хранимых процедур, которые возвращают любые предоставленные мной объекты, которые не обязательно совпадают с таблицами БД
• обеспечивают хорошее отображение объектов из читателя данных в объекты
• поддерживает отношения (все они)
• необязательная (но желательная) поддержка нескольких результатов набора результатов
• не требует специальной настройки (я использую только подключение к данным)строка и ничего больше)

По сути, он должен быть очень легковесным, просто должен иметь простую оболочку Ado.net и объектный сопоставитель.

И самое важное требование: прост в использовании, хорошо поддерживается, и сообщество использует его .

Answer 1

Альтернативы (май 2011)

Я вижу, что большие пушки преобразовали свои стратегии доступа в инструменты микро ORM.Я играл с той же идеей, когда оценивал BLToolkit, потому что он был громоздким (1,5 МБ) для функциональности, которую я бы использовал.В конце концов я решил написать вышеупомянутый T4 (рассматриваемая ссылка), чтобы облегчить мою жизнь при вызове хранимых процедур.Но в BLToolkit все еще есть много возможностей, которые я вообще не использую или даже не понимаю (причины также указаны в вопросе).

Лучшая альтернатива - инструменты микро ORM .Может быть, было бы лучше назвать их микрообъектами .Все они имеют одинаковые цели: простота и предельная скорость .Они не следуют парадигме NoSQL их больших собратьев ORM, поэтому большую часть времени нам приходится писать (почти) ежедневный TSQL для поддержки своих запросов.Они извлекают данные и сопоставляют их с объектами (и иногда предоставляют что-то большее - проверьте ниже).

Я хотел бы указать на 3 из них.Все они представлены в одном файле кода, а не в виде скомпилированной DLL:

• Dapper - используется Stackoverflow ;все, что он на самом деле делает, это предоставляет общие методы расширения для IDbConnection, что означает, что он поддерживает любое резервное хранилище данных, пока есть класс соединения, который реализует интерфейс IDbConnection;
  • использует параметризованный SQL
  • сопоставляет со статическими типами, а также dynamic (.net 4 +)
  • поддерживает сопоставление нескольким объектам для каждой записи результата (как в 1-1 отношение, т.е. Person + Address)
  • поддерживает сопоставление объектов с несколькими результирующими наборами
  • поддерживает хранимые процедуры
  • сопоставления генерируются, компилируются (MSIL) и кэшируются -это также может быть недостатком, если вы используете огромное количество типов)
• Massive - написанный Робом Коннери;
  • поддерживает только отображение типов dynamic (не поддерживается в .net 3.5 или более ранних версиях)
  • очень мало (несколько сотен строк кода)
  • обеспечивает *Класс 1054 *, от которого наследуются ваши сущности, и предоставляет функции CRUD * или сопоставления с произвольной базовой металией TSQL
  • Поддержка неявного разбиения на страницы
  • поддерживает сопоставление имен столбцов (но вы должны это сделатькаждый раз, когда вы обращаетесь к данным, а не к декларативным атрибутам)
  • поддерживает хранимые процедуры путем написания прямого параметризованного TSQL
• PetaPoco - вдохновил мой Massive, но стребование поддержки более старых версий фреймворка
  • поддерживает строгие типы, а также dynamic
  • предоставляет шаблон T4 для генерации ваших POCO - в итоге вы получите классы, похожие на большие классы ORM (которыеозначает, что code-first не поддерживается) , но вам не нужно использовать эти , вы, конечно же, можете написать свои собственные классы POCO, чтобы сохранить свою модель lightweigи не включать в БД только информацию (т.е.отметки времени и т. д.)
  • аналогично Dapper, он также компилирует сопоставления для скорости и повторного использования
  • поддерживает операции CRUD + IsNew
  • неявная поддержка подкачки, которая возвращает специальный тип со страницей-полнота данных + все метаданные (текущая страница, количество всех страниц / записей)
  • имеет точку расширения для различных сценариев (ведение журнала, преобразователи типов и т. д.)
  • поддерживает декларативные метаданные (столбец / таблица)сопоставления и т. д.)
  • поддерживает сопоставление нескольких объектов для каждой записи результата с некоторыми автоматическими настройками отношения (в отличие от Dapper, где необходимо вручную подключать связанные объекты)
  • поддерживает хранимые процедуры
  • имеет вспомогательный класс SqlBuilder для упрощения построения операторов TSQL

Из всех трех PetaPoco кажется самым живым с точки зрения разработки и поддержки большинства вещейвзяв лучшее из двух других (и некоторых других).

Из всех трех Dapper имеет лучший реальный эталон использования, потому что он используется одним из сайтов с самым высоким трафиком в мире: Stackoverflow.

Все они страдают от проблемы с магическими строками, потому что большую часть времени вы пишете SQL-запросы прямо в них. Но некоторые из них могут быть смягчены с помощью T4, так что вы можете иметь строго типизированные вызовы, которые обеспечивают проверку целостности, проверку во время компиляции и повторную генерацию на лету в Visual Studio.

Недостаток dynamic типа

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