「マイクロソフト系技術情報 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 Bean(POCO)と、根本的に異なる。
Entity Frameworkは高機能で複雑なため、
ORM自体の問題と、切り分けが難しい別の問題を持っている。
特徴 †
以下のような、３つの開発スタイルがある。
- DBファースト
- DB設計者（DA、DBA）の設計したDBを使用する。
- 基幹系システムやビジネス・アプリケーションではコチラを使用する事が多いと思われる。
- コードファースト
- Entityの設計がDBスキーマに反映される。既存DBにも適用可能。
- 以下の様なシステム・アプリケーションではコチラを使用する事があると思われる。
- クライアント・アプリケーション
- プロトタイプ・モックアップのデータアクセス部の開発
- SQLを駆使しない、データアクセスが比較的簡単なシステム・アプリケーション
適合するシステム・アプリケーション †
- データをオブジェクトとして保持しセーブ・ロードを繰り返すようなシステム（オンライン・ゲームなど）。
- 単純なユーザ・ストアにアクセスして、ユーザ・データを更新するようなシステム。
- １ページ、１テーブル（ビュー）＆１トランザクション的な、割りきった作りのシステム。
- 例えば、クライアント・アプリケーションや、前述のシステム・アプリケーションに合致しないサービスなど。
参考 †
以下が参考になる。
Dapperは単純な分、ORMの良さや悪さを分析し易い。
特徴 †
- 厳密に言えば、ORMではなく、Micro-ORM（DataMapper?とかTableMapper?）。
- SQL（の入出力パラメタ）と、Bean(POCO)の間のマッピングを行う。
感想 †
Dapperを使って認証基盤のユーザストアの永続化を実装してみた感想。
- （Dapperは正確にはORMではないが、同様に、）複雑なデータアクセスは弱い。
- ただしRDBMSをNoSQLやX.500などのストアとコンパチにするような実装の場合は、
オブジェクト <---> ストア的な実装が必要とされるので、用途次第で適合する可能性はあると言える。
適合するシステム・アプリケーション †
以下の様なケースでは、Dapperがイイのでは無いかと考える。
- データストア、データアクセスが単純なケース。
- サーバーをJSON吐く土管化するようなケース。
- RDBMSをNoSQLやX.500などのストアとコンパチにするようなケース
分析 †
データアクセスのフレームワーク、其々に、
- 生のデータプロバイダ系はSQL編集処理の柔軟性が高いが、
- ORM系は、コーディングが容易化されているが、SQL編集処理の柔軟性が低い。
（Bean(POCO)側が静的なので、SQL側だけ動的化するインターフェイスを実装できない）
などのトレードオフがある。
このため、アプリケーションの特性によって、
そのデータアクセスのフレームワークが適合するか？しないか？がある。
※ 例えば、基本的なORM実装では、オブジェクト操作と永続化操作は切り離されており、
オブジェクトに対する変更を無造作に更新するため、未更新の列なども更新対象になる。
（基本的に、未更新列を更新対象から外すなどの、きめ細かな操作はしない。）
参考 †
Tags: :データアクセス, :.NET開発, :ADO.NET, :Entity Framework
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
