ORM戦略の選択（.NET）

開発者が犯す間違いの1つ（かつて私はそれらの1つでした）は、作成するアプリケーションに対してORM戦略を1つだけ使用する必要があるというステートメントです。 これは一般的に真実ではありません。 戦略の選択を特定のシナリオに結び付けることができ（またそうすべきです）、特定のケースに適したツールを選択するようにしてください。



ADO.NETを直接使用するべきではない時間の99.9％がすぐにわかります。 まだdataReader.MoveNext



を使用している場合-停止してください！



多くの人はORMが好きではありません。 彼らの議論を聞いた後、Martin FowlerがOrmHateで書いたことに同意します 。

ORMからの最大の失望は、高い期待にあります。

ORMは悪い、い、過負荷であるという考えに同意する必要があります 。 ORMは、問題を解決するために設計されており、このためのさまざまなアプローチがあります。 しかし、これらのアプローチを検討する前に、解決しようとしている問題を調べてみましょう。

ギャップを埋める

SQLでデータをロードまたは埋め込む必要がある場合は、SQLで.NETデータ型をマップ（「マップ」）する必要があります。 .NETの場合、これはADO.NETを使用してSQLコマンドをSQLサーバーに送信することを意味します。 次に、SQLタイプを.NETタイプにマップする必要があります。 また、微妙な違いもあります。たとえば、SQLの日付は.NETの日付とは異なります。



ADO.NETはこれを支援しますが、生データセットの処理と.NETオブジェクトの作成の仕事を残します。 最終的に、必要なものが得られます。オブジェクトと.NETタイプを操作します。 また、一部のコードはこれをSQLクエリに変換し、その逆も行います。



ORMは、ADO.NETの上にさまざまな抽象化のレイヤーを追加することにより、この問題を解決するように設計されています。 しかし、これには多くの戦略があります。 それぞれを見て、どれが最も適しているかを見てみましょう。

エンティティベースのリレーショナルマッピング

このようなマッピングでは、ほとんどの場合、データベーステーブルはシステムのエンティティと1対1で対応しています。 オブジェクトにプロパティを追加すると、テーブルに列が追加されます。 このメソッドの使用は、その識別子によってエンティティ（または集約）を読み込み、このオブジェクトと、場合によっては関連オブジェクトを管理し、ORMを使用してこのオブジェクトをデータベースに保存することに基づいています。



この場合のORMは、次のような多くの機能を提供します。

• 変更追跡
• 遅延読み込み（遅延読み込み）
• プリロード（積極的なフェッチ）
• カスケード
• オブジェクトの一意性の確保（ アイデンティティマップ ）
• 作業単位で作業する（作業単位 ）

一度に1つのエンティティまたは集計のみを操作する場合、NHibernateなどのORMは非常に適しています。 指定された構成を使用して、読み込まれたエンティティを追跡し、トランザクションのコミット中に変更を自動的に保存します。 また、これは素晴らしいことです。なぜなら、データを扱う独自のレイヤーを持ち歩くべきではないからです。 NHibernateがすべての汚い仕事をしてくれます。



オブジェクトを変更するという唯一の目的でIdによってオブジェクトをロードする限り、これはすべて正常に機能します。 これにより、オブジェクトの追加、保存などを追跡するために作成する必要のある大量のコードが不要になります。



このアプローチの裏側は、オブジェクトを読み込むだけか、それを変更するためにエンティティをロードするかをORMが認識しないことです。 デフォルトでは、変更追跡が有効になっていることに気づかないと、人々はつまずきます。



エンティティをロードして変更を保存する（または新しいエンティティを作成する）ためにエンティティをロードする場合、このアプローチにより、インフラストラクチャレイヤーにデータアクセスレベルを含めることで柔軟性が高まり、エンティティタイプを保存方法から比較的独立させることができます。 この独立性は、C＃モデルとデータスキーマが異なる可能性があることを意味するものではありません。 それどころか、これは、データアクセス層がオブジェクトモデルを貫通しないことを意味します。代わりに、ビジネスルールをロードすることを好みます。

データセットへのマッピング（結果セットベースのリレーショナルマッピング）

ほとんどのアプリケーションでは、データ読み取り要件がレコード数をはるかに超えています。 最近のアプリケーションでは、SELECTとINSERT / UPDATE / DELETEの比率が100：1でした。 SQLが本当に得意とするものを見ると、SQLはセット（セット）内のデータを処理しています。 SQLサーバーからデータセットを選択する場合、このデータをエンティティに直接マップしようとすることは意味がありません。



ただし、IDataReaderまたはDataTableを直接操作することは避けます。 これらは、アプリケーションの上位層に転送するのが難しい、型指定の悪いオブジェクトです。 それどころか、データに適合したオブジェクトを作成することがよくあります。 これらのオブジェクトは、多くの場合、DTO（データ転送オブジェクト）または読み取りモデルと呼ばれます。 個々のSQLサンプルに対してこのようなDTOを作成しますが、他のクエリでそれらを再利用することはほとんどありません。



多くのORMには、このようなシナリオ向けに最適化された機能があります。 NHibernateでは、投影を使用して追跡をオフにし、データをDTOに直接表示できます。 SQLクエリを使用してこれを行うことができ、マッピング構成は必要ありません。 または、PetaPocoのようなマイクロORMを使用できます。



これらの読み取りは、読み取り時にDTOオブジェクトを生成することもできます。 NHibernateと複数のmicro-ORMの両方を使用すると、クエリ結果行を読み取りながら個々のDTOオブジェクトを1つずつ順番に受信できるため、メモリに含まれるオブジェクトの量を最小限に抑えることができます。



アプリケーションでは、読み取りにNHiberanteを使用することがよくありますが、エンティティオブジェクトは使用せず、代わりに生のSQLを使用します。 最適化されたNHiberanateマッパーを使用して、DTOタイプを提供するだけで、選択の結果が自動的に表示されます。

ビジネスルールを適用して情報を保存する必要がある場合、このアプローチはうまく機能しません。 これらのモデルは通常、個別のデータセットに表示されますが、データベーステーブルには表示されません。



アクティブレコードは、データを操作するための機能がオブジェクトモデル自体に含まれているデータの基本的な表示の別の例です。

DMLベースのリレーショナルマッピング

CRUDの実装に必要なSQLがわかっていて、手動で作成したい場合は、DMLコマンドをADO.NETよりも高いレベルに効果的に抽象化するものをすでに探しています。

そして、これがマイクロORMアリーナです。 PetaPoco 、 Dapper 、 Massiveなどのフレームワークは、ADO.NETの問題を解決するために作成されています。 通常は、ADO.NETオブジェクトを操作できますが、操作は大幅に簡素化されています。 接続が必要なだけで、これらのフレームワークでは、ADO.NET自体よりもはるかに単純なコードを提供する形式ですべてのCRUD操作を処理できます。



エンティティがなく、エンティティをテーブルに表示する必要がある場合、またはその逆の場合、micro-ORMははるかに簡単なアプローチを提供します。 また、マイクロORMは事前の構成を必要としないため、遅延実行と最適化されたキャッシングテクニックに依存して、SQLパラメーターをマップし、結果をクエリします。 多くのアプリケーションはDMLベースのmappigで開始でき、関係またはエンティティが必要に応じてすぐに本格的なORMに切り替えることができます。

一括読み込みツール

これは特別な場所を占有するものです-オブジェクトの方法でデータを挿入/ロードしたくない場合があります。 代わりに、すべてのセットをまとめて使用することをお勧めします。 SQL Bulk Copyなどのツールを使用すると、データをCSV形式または表形式で取得およびアップロードできます。



これらのユーティリティはバズーカのように機能し、すべてのデータをすぐにやり取りしますが、それ以外は提供しません。 データを更新または削除することはできませんが、SQLから大量のデータを取得するには、これらのユーティリティが必要です。



データファイルを外部パートナーに提供する、またはその逆の多くの統合シナリオでは、これらのダウンローダーを使用して、ファイルをテーブルとして使用し、データベースに直接アップロードできます。



これらのユーティリティは、データを解析/ロードする従来の方法よりもはるかに高速です。 一部のテストでは、プログレッシブロードと比較して順序に違いが見られました。 そして、あるケースでは、数時間と1分間の違いを見ました。 これらすべての裏返しは、機能がINSERTとSELECTのみに制限されていることです。 他のすべてには、他のアプローチが必要です。

タスクに最適なツール

最近のプロジェクトでは、上記の各アプローチを使用して、1つのデータベースと1つのコードを操作しました。 エンティティ/集計マッピング用のNHibernate、データセットを読み込むための既製の結果セットの選択（および結果のメッセージ/エクスポート/ビューの追加準備）、シンプルなテーブルとモジュールのDMLマッピング、およびパートナーからファイルをダウンロードするためのバルクロードツール何百万ものラインで。



重要な点は、特定のツールやアプローチに縛られる必要がないことです。 すべてのシナリオでORM戦略は機能しません。 NHibernateは他の多くのシナリオ（エンティティの直接マッピングを除く）で動作できますが、世界では何もしません。 常に同じアプローチを使用しようとする試みから複雑さがしばしば生じる。



SQLサーバーの外部で記述されたすべてのアプリケーションはORMを使用します。 この手書きADO.NETコードまたはNHibernateのいずれか-.NETとSQLの間のギャップを埋める必要があります。 この克服は困難な作業であり、問​​題を完全に解決するものはありません。 そして、すべきではありません！



特定の問題を解決するアプローチを選択してください。 1つのプロジェクトに複数のORM戦略があることを心配しないでください。 これは、非体系的な解決策が受け入れられるという意味ではありません。 しかしそれどころか、可能なオプションの知識に基づいて検証済みのソリューションを適用することは常に良い考えです。