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

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

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

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

минус

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

вопрос

какие альтернативы у меня есть для BLToolkit что:

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

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

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

6
bltoolkit mapping stored-procedures

1 ответов

Альтернативы (Май 2011 Года)

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

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

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

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

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

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

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

минус dynamic тип

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

4