Каковы некоторые из преимуществ «микро-ORM»?

Я изучал так называемые «микро ORM», такие как Dapper и (в меньшей степени, поскольку он опирается на .NET 4.0), поскольку они могут быть проще в работе, чем полноценный ORM, так как наша текущая система сильно зависит от хранимых процедур и потребует значительного рефакторинга для работы с 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 вам нужно выполнить (что может стать проблематичным) и вам все еще нужно отобразить отношения между таблицами (часть, с которой ORMs IMHO помогают больше всего).

Выгоды:

• Производительность аналогична сырой SqlCommand с DataReader и синтаксическим анализом.
• Не нужно накатывать собственный конверсионный слой для DataReader.

Вот и все, честно говоря. У вас есть очень легкая оболочка для ваших sql-соединений, которая сделает преобразование объекта за вас. Очевидно, что вы можете точно настроить запросы без необходимости иметь дело с каким-либо автоматически сгенерированным SQL.

Минусы:

• Даже немного небезопасно. Если вы сделаете опечатку в SQL, которую ваш сервер CI не поймает, вам придется надеяться, что она будет обнаружена во время автоматизированного пользовательского интерфейса или функционального тестирования.
• Боль поддерживать. У вас есть несколько встроенных операторов SQL, которые выполняют различные запросы, которые не имеют прочных связей с архитектурой БД. Это может довольно легко привести к запросам, которые «отстают» при изменении базовой структуры БД, что, опять же, вы не увидите во время сборки.

У них есть свое место, и они являются очень эффективным инструментом, который может отнять у разработчиков некоторую «работу осла» при взаимодействии с БД, но в действительности они просто не могут заменить полноценный ORM в любом крупномасштабном Система для запросов, которые не критичны к производительности, просто из-за увеличения затрат на обслуживание.

Если вы боретесь с производительностью запросов к БД, я бы предположил, что было бы лучше использовать эти структуры сопоставления только с хранимыми процедурами, чтобы получить во время компиляции указание на то, что ваш 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, вам необходимо использовать полнофункциональное. Это и код относительно меньше, поэтому, если вам нужно настроить его, это будет проще.