Які є переваги "Micro-ORM"?

Я розглядав так звані "мікро-ORM", як Dapper, і (в меншій мірі, оскільки він покладається на .NET 4.0) масивний, оскільки це може бути легше впровадити на роботі, ніж повноцінний ORM з нашої нинішньої системи дуже залежить від збережених процедур і потребує значного рефакторингу для роботи з ОРМ, як NHibernate або EF. Яка користь від використання одного з них у повнофункціональному ORM? Це здається просто тонким шаром навколо з'єднання з базою даних, який все ще змушує вас писати необроблений SQL - можливо, я помиляюся, але мені завжди казали причину ORM в першу чергу, тому вам не довелося писати SQL, це можна автоматично генерувати; особливо для приєднань до декількох таблиць та відображення взаємозв'язків між таблицями, які є більшим завданням у чистому SQL, але тривіально з ORM.

Наприклад, дивлячись на приклад Dapper:

var connection = new SqlConnection(); // setup here...
var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 });

Як це відрізняється від використання рівня керованого рівня даних ADO.NET, за винятком того, що вам не потрібно писати команду, встановлювати параметри, і я припускаю, що об'єднати об'єкт назад за допомогою Builder. Схоже, ви навіть можете використовувати збережений виклик процедури як рядок SQL.

Чи є інші відчутні переваги, які мені не вистачає, де Micro ORM має сенс використовувати? Я насправді не бачу, як це економить що-небудь на "старому" способі використання ADO.NET, за винятком, можливо, декількох рядків коду - вам все одно потрібно написати, щоб зрозуміти, який SQL потрібно виконати (який може бути волохатим) і вам все одно доведеться відображати взаємозв'язки між таблицями (частина, з якою найбільше допомагають ІМХО ORM).

.net orm

— Уейн Моліна
джерело

+1: Ви все одно будете потребувати мови запиту незалежно від того, тому ви можете також дотримуватися чогось знайомого, як linq або sql, але повернення анонімних типів, як у вашому прикладі, схоже, не позначає реляційну модель на конкретоване домен модель. Це стикається як не дивно для мене.

— Стівен Еверс

Так, я не міг знайти конкретного прикладу Dapper, на сайті він буквально це робить, var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });а потім dog.First().Ageотримати доступ до властивостей.

— Уейн Моліна

Приклад не повертає анонімний тип, ключове слово "var" може бути використане замість конкретного типу в C #, щоб зберегти зайвий набір тексту, цей запит поверне IEnumerable <Person>.

— Ед Джеймс

Основна причина - менше накладних витрат, щоб постійно перевіряти паростки, а потім не забувати оновлювати два десятки файлів SQL, не кажучи вже про необхідність зберігання програм для тривіального коду CRUD.

— Уейн Моліна

Основна перевага - не використовувати відростки для збереження всього коду (і я тут спеціально використовую код, включаючи SQL та інші ваші мови на вибір) в одній і тій же системі контролю версій. Я ще не стикався з гарною базою даних VCS для крос-DB.

— Ед Джеймс

Відповіді:

Переваги:

Аналогічна продуктивність для сирої SqlCommand з DataReader та синтаксичним розбором.
Немає необхідності прокручувати власний рівень перетворення для DataReader.

Чесно це, чесно кажучи. У вас є дуже легка обгортка для ваших з'єднань sql, яка зробить перетворення об'єкта за вас. Очевидно, ви можете точно налаштувати запити, не маючи справу з будь-яким автогенерованим SQL.

Мінуси:

Навіть трохи не безпечно. Якщо ви зробите помилку на друку в SQL, ваш сервер CI не збирається його спіймати, вам доведеться сподіватися, що він потрапив під час автоматизованого інтерфейсу або функціонального тестування.
Біль для підтримки. У вас є купа вбудованих операторів SQL, які виконують різні запити, які не мають міцних зв’язків з архітектурою БД. Це може досить легко призвести до запитів, які «залишаються позаду» при зміні основної структури БД, що, знову ж, ви не побачите під час збирання.

У них є своє місце, і вони є дуже ефективним інструментом, який може забирати частину "роботи ослів" у розробників при взаємодії з БД, але насправді вони просто не можуть зайняти місце повноцінної ОРМ у будь-яких великих масштабах система запитів, які не є критичними для продуктивності, просто через збільшення витрат на обслуговування.

Якщо ви боретеся з ефективністю запитів БД, я б припустив, що було б краще використовувати ці структури картографування лише із збереженими процедурами, щоб отримати вказівку часу компіляції, чи дійсний ваш SQL (плюс додаткові переваги продуктивності) .

— Ед Джеймс
джерело

Є бібліотеки, які можна використовувати як обгортку для цих мікроорганізмів, що може зменшити проблему, яку ви згадуєте при друкуванні. Напр.: Простий додаток для

— сирця

На веб-сайті мікро ORM PetaPoco він пояснює певну перевагу перед іншими ORM. щоб пояснити більше

PetaPoco - це крихітний, швидкий однофайловий мікро-ORM для .NET та Mono.

Як і Massive - це єдиний файл, який ви легко додаєте до будь-якого проекту

На відміну від Massive, він працює з сильно набраними POCO

Як і Massive, тепер він також підтримує динамічні Expandos - читайте більше

Як і ActiveRecord, він підтримує тісний зв’язок між об'єктом і таблицею баз даних

Як і SubSonic, він підтримує покоління класів poco з шаблонами T4

Як і Dapper, це швидко, оскільки він використовує динамічну генерацію методу (MSIL) для присвоєння значень стовпців властивостям

— Крістоф Вищий
джерело

Як це відрізняється від використання рівня керованого рівня даних ADO.NET, за винятком того, що вам не потрібно писати команду, встановлювати параметри, і я припускаю, що об'єднати об'єкт назад за допомогою Builder. Схоже, ви навіть можете використовувати збережений виклик процедури як рядок SQL.

Я вважаю, що це головна перевага Micro-ORM, щоб отримати інші переваги ORM, вам потрібно використовувати повний видув. Це і код порівняно менше, тому, якщо вам потрібно налаштувати його, це було б простіше.

— Чорний лід
джерело