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

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

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

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

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

• Dapper - used by Stackoverflow itself; all it actually does it provides generic extension methods over IDbConnection which means it supports any backing data store as long there's a connection class that implements IDbConnection interface;
  • uses parametrised SQL
  • сопоставляется со статическими типами, а также с dynamic (.net 4+)
  • поддерживает сопоставление с несколькими объектами для каждой записи результата (как в отношениях 1-1, т.е. Person+Address)
  • поддерживает сопоставление объектов с несколькими наборами результатов
  • поддерживает хранимые процедуры
  • сопоставления генерируются, компилируются (MSIL) и кэшируются — это также может быть недостатком, если вы используете огромное количество типов)
• Massive - written by Rob Connery;
  • only supports dynamic type mapping (no support in .net 3.5 or older baby)
  • чрезвычайно мал (несколько сотен строк кода)
  • предоставляет класс DynamicModel, от которого наследуются ваши объекты, и предоставляет функции CRUD или карты из произвольного чистого TSQL.
  • неявная поддержка пейджинга
  • поддерживает сопоставление имен столбцов (но вам нужно делать это каждый раз, когда вы обращаетесь к данным, а не к декларативным атрибутам)
  • поддерживает хранимые процедуры путем написания прямого параметризованного TSQL
• PetaPoco - inspired my Massive but with a requirement to support older framework versions
  • supports strong types as well as dynamic
  • предоставляет шаблон T4 для создания ваших POCO - вы получите классы, похожие на классы больших ORM (это означает, что code-first не поддерживается) но вам не нужно использовать их, вы все равно можете конечно, напишите свои собственные классы POCO, чтобы ваша модель была легкой и не включала только информацию о БД (например, временные метки и т. д.)
  • аналогично Dapper, он также компилирует сопоставления для скорости и повторного использования.
  • поддерживает операции CRUD + IsNew
  • неявная поддержка разбиения по страницам, которая возвращает специальный тип с полной страницей данных + все метаданные (текущая страница, количество всех страниц/записей)
  • имеет точку расширения для различных сценариев (логирование, преобразователи типов и т.д.)
  • поддерживает декларативные метаданные (сопоставления столбцов/таблиц и т. д.)
  • поддерживает сопоставление нескольких объектов для каждой записи результата с некоторыми автоматическими настройками отношений (в отличие от Dapper, где вам нужно вручную подключать связанные объекты)
  • поддерживает хранимые процедуры
  • имеет вспомогательный класс SqlBuilder для упрощения построения операторов TSQL.

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

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

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

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

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