「Micro-ORM」の利点は何ですか？

私は現在のシステム以来、本格的なORMよりも職場での実装が簡単である可能性があるため、Dapperや（.NET 4.0に依存しているためそれほどではありませんが）いわゆるいわゆる「マイクロORM」を検討しています。ストアドプロシージャに大きく依存しているため、NHibernateやEFなどのORMを使用するには、大幅なリファクタリングが必要になります。フル機能のORMよりもこれらの1つを使用する利点は何ですか？データベース接続を取り巻く薄いレイヤーのように見えますが、それでも未加工の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 });

コマンドを記述したり、パラメータを設定したり、Builderを使用してエンティティをマップし直したりする必要がないことを除いて、ハンドロールADO.NETデータレイヤーの使用とはどのように違いますか。ストアドプロシージャコールをSQL文字列として使用することもできるようです。

Micro ORMを使用する意味がある場合、ここで見逃している他の具体的な利点はありますか？おそらく数行のコードを除いて、ADO.NETを使用する「古い」方法で何かを保存する方法を実際には見ていません-実行する必要があるSQLを把握するために書く必要があります。テーブル（IMHO 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プロパティにアクセスするためのサイトで。

— ウェインモリナ

この例では匿名型は返されません。C＃の具象型の代わりに「var」キーワードを使用して余分な入力を保存できます。このクエリはIEnumerable <Person>を返します。

— エドジェームズ

主な理由は、sprocsを絶えずチェックインしてから、ダースなCRUDコード用にprocsを保存しなければならないことは言うまでもなく、数十個のSQLファイルを更新することを忘れないためのオーバーヘッドが少ないことです。

— ウェインモリナ

すべてのコードを保持するためにsprocを使用しないことの主な利点（およびここでは、SQLと他の選択言語を含む意図的にコードを使用します）を同じバージョン管理システムに保持します。まだ、優れたクロスデータベースデータベースVCSに出会っていません。

— エドジェームズ

回答:

利点：

DataReaderと解析を使用した生のSqlCommandと同様のパフォーマンス。
DataReaderの独自の変換レイヤーをロールする必要はありません。

正直に言うと、それだけです。オブジェクトの変換を行うSQL接続への非常に軽量なラッパーがあります。もちろん、自動生成されたSQLを処理することなく、クエリを微調整できます。

短所：

少しでもタイプセーフではありません。CIサーバーがそれをキャッチしないSQLでタイプミスをした場合、自動UIまたは機能テスト中にキャッチされることを期待する必要があります。
維持するための痛み。DBアーキテクチャとは強力な関係のないさまざまなクエリを実行するインラインSQLステートメントがたくさんあります。これにより、基礎となるDB構造が変更されたときに「置き去り」にされるクエリが非常に簡単に発生する可能性があります。

DBを操作するときに開発者から「ロバ作業」の一部を取り除くことができる非常に効果的なツールですが、実際には大規模なORMの代わりになることはできません。メンテナンスコストの増加のためだけに、パフォーマンスが重要ではないクエリのシステム。

DBクエリのパフォーマンスに苦労している場合は、SQLが有効であるかどうかのコンパイル時の表示を取得するために、これらのマッピングフレームワークをストアドプロシージャのみで使用することをお勧めします（および追加のパフォーマンスの利点）。

— エド・ジェームス
ソース

これらのマイクロオームのラッパーとして使用できるライブラリがあり、タイプミスで言及している問題を軽減できます。例：Dapper用のシンプルなCrudアドオン

— Srivathsa Harish Venkataramana

micro ORM PetaPocoの Webサイトで、彼は他のORMの利点を説明しています。もっと説明する

PetaPocoは、.NETおよびMono用の小さくて高速な単一ファイルのマイクロORMです。

Massiveのように、プロジェクトに簡単に追加できる単一のファイルです

Massiveとは異なり、強く型付けされたPOCOで動作します

Massiveと同様に、動的なExpandosもサポートするようになりました-続きを読む

ActiveRecordのように、オブジェクトとデータベーステーブル間の密接な関係をサポートします

SubSonicと同様に、T4テンプレートを使用したpocoクラスの生成をサポートします

Dapperと同様に、動的メソッド生成（MSIL）を使用してプロパティに列の値を割り当てるため、高速です。

— クリストフ・デボベ
ソース

コマンドを記述したり、パラメータを設定したり、Builderを使用してエンティティをマップし直したりする必要がないことを除いて、ハンドロールADO.NETデータレイヤーの使用とはどのように違いますか。ストアドプロシージャコールをSQL文字列として使用することもできるようです。

これがMicro-ORMの主な利点であり、ORMの他の利点を得るには、本格的なORMを使用する必要があると思います。それとコードは比較的小さいので、カスタマイズする必要がある場合は簡単です。

— BlackICE
ソース