「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ADO.NET、Entity Framework、Dapper、その他の選択肢のどれを選ぶべきか？
トレードオフがあるので、新しい技術を使っておけばイイという訳には行かない模様。
分析 †
データアクセスのフレームワークにも、
というトレードオフがある。
このため、アプリケーションの特性によって、
そのデータアクセスのフレームワークが適合するか？しないか？がある。
SQLを使用して、二次元表形式の論理データを自由に取得できる。
DataReader?, DataSet? †
特徴 †
Bean(POCO)にORMではなく、論理データ独立な二次元表（DataSet?、DataTable?）を使用できる。
- DataAdapter は DataSet? オブジェクトとデータ ソース間のブリッジとして機能する。
- DataSet? の機能が必要ない場合は、DataReader? を使用したほうが性能が向上する。
- 非接続型データアクセスを実行する場合はDataSet?を使用する。
- データをローカルにキャッシュし操作する場合。
- サーバーで取得・更新、クライアントで編集等、
物理境界を超えてデータを持ち回って処理を行う場合。
- Windows フォーム コントロールとの連結し、対話的に編集をする場合など。
DataSet
├DataRelationCollection
├ExtendedProperties
└DataTableCollection
└DataTable
├DataColumnCollection─DataColumn─ExtendedProperties
├PrimaryKey
├Constraints
├ChildRelations
├ParentRelations
├ExtendedProperties
├DataView
├DataRowCollection─DataRow
Bean(POCO)変換 †
実装は、それ程、難しくない。
適合するシステム・アプリケーション †
- 情報系システム
- 多種・多様なビュー（二次元表形式の論理データ）にアクセスする。
- 参照先のテーブルや取得するカラムを動的に変更するようなシステム。
- 基幹系システム
- 複雑なデータクセスに対応する柔軟性と、
大量データの処理に対応するパフォーマンスを両立させる必要があるシステム。
- 参照したビュー（二次元表形式の論理データ）を元に更新処理を行なうシステム。
ORM的なソリューションだが、
特徴 †
適合するシステム・アプリケーション †
- JIONなどもサポートしているもよう（下記参照）。
- 今となっては、中途半場で、あまり利用されていない。
特徴 †
適合するシステム・アプリケーション †
- SQL編集処理が複雑になるエンプラのドメインで使える。
- SQL定義をパラメタセットによって編集したい（S2DaoやiBATISのように）。
- メソッド（＝LINQのメソッド ベースのクエリ構文（メソッドチェーンやラムダ式））
でクエリ編集という方式は、エンプラのドメインに必要とされる柔軟性が足りない。
ORM系 †
- 基本的にSQLを使用せず、概念スキーマに準拠したオブジェクトにデータをストアする。
- プログラム側のデータの持たせ方が2次元表 vs ORMと、根本的に異なる。
特徴 †
以下のような、３つの開発スタイルがある。
- DBファースト
- DB設計者（DA、DBA）の設計したDBを使用する。
- 基幹系システムやビジネス・アプリケーションではコチラを使用する事が多いと思われる。
- コードファースト
- Entityの設計がDBスキーマに反映される。既存DBにも適用可能。
- 以下の様なシステム・アプリケーションではコチラを使用する事があると思われる。
- クライアント・アプリケーション
- プロトタイプ・モックアップのデータアクセス部の開発
- SQLを駆使しない、データアクセスが比較的簡単なシステム・アプリケーション
適合するシステム・アプリケーション †
- データをオブジェクトとして保持しセーブ・ロードを繰り返すようなシステム（オンライン・ゲームなど）。
- 単純なユーザ・ストアにアクセスして、ユーザ・データを更新するようなシステム。
- １ページ、１テーブル（ビュー）＆１トランザクション的な、割りきった作りのシステム。
- 例えば、クライアント・アプリケーションや、前述のシステム・アプリケーションに合致しないサービスなど。
- 補足
エンタープライズ分野のビジネス・アプリケーションでは、
「RDBMSの複数テーブル＆ビューを参照して、テーブル単位に更新する。」
という処理になりがちで、この処理がそもそもORMに適合しない。
Dapperは単純な分、ORMの良さや悪さを分析し易い。
特徴 †
- 厳密に言えば、ORMではなく、Micro-ORM（DataMapper?とかTableMapper?）。
- SQL（の入出力パラメタ）と、Bean(POCO)の間のマッピングを行う。
感想 †
Dapperを使って認証基盤のユーザストアの永続化を実装してみた感想。
- （Dapperは正確にはORMではないが、）複雑なデータアクセスは弱い。
- ただしNoSQLやX.500などユーザ・ストアを可変にするような実装の場合、
オブジェクト <---> ストア的な実装が汎用的で且、必要とされるので、用途次第。
適合するシステム・アプリケーション †
以下の様なケースでは、Dapperがイイのでは無いかと考える。
- データストア、データアクセスが単純なケース。
- サーバーをJSON吐く土管化するようなケース。
参考 †
Tags: :データアクセス, :.NET開発, :ADO.NET, :Entity Framework
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
