マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

ADO.NETEntity FrameworkDapper、その他の選択肢のどれを選ぶべきか?
トレードオフがあるので、新しい技術を使っておけばイイという訳には行かない模様。

生のデータプロバイダ系(ADO.NET)

SQLを使用して、二次元表形式の論理データを自由に取得できる。

DataReader?, DataSet?

特徴

Bean(POCO)にORMではなく、論理データ独立な二次元表(DataSet?DataTable?)を使用できる。

  • DataAdapterDataSet? オブジェクトとデータ ソース間のブリッジとして機能する。
  • DataSet? の機能が必要ない場合は、DataReader? を使用したほうが性能が向上する。
  • 非接続型データアクセスを実行する場合はDataSet?を使用する。
    • データをローカルにキャッシュし操作する場合。
    • サーバーで取得・更新、クライアントで編集等、
      物理境界を超えてデータを持ち回って処理を行う場合。
    • Windows フォーム コントロールとの連結し、対話的に編集をする場合など。
DataSet
├DataRelationCollection
├ExtendedProperties
└DataTableCollection
 └DataTable
  ├DataColumnCollection─DataColumn─ExtendedProperties
  ├PrimaryKey
  ├Constraints
  ├ChildRelations
  ├ParentRelations
  ├ExtendedProperties
  ├DataView
  ├DataRowCollection─DataRow

Bean(POCO)変換

実装は、それ程、難しくない。

適合するシステム・アプリケーション

  • 情報系システム
    • 多種・多様なビュー(二次元表形式の論理データ)にアクセスする。
    • 参照先のテーブルや取得するカラムを動的に変更するようなシステム。
  • 基幹系システム
    • 複雑なデータクセスに対応する柔軟性と、
      大量データの処理に対応するパフォーマンスを両立させる必要があるシステム。
    • 参照したビュー(二次元表形式の論理データ)を元に更新処理を行なうシステム。

DataAdapter, TableAdapter

ORM的なソリューションだが、
今となっては、中途半場で、あまり利用されていない。

特徴

適合するシステム・アプリケーション

JIONなどもサポートしているもよう(下記参照)なので、
頑張れば、情報系システム、基幹系システムへの応用も可能と思われる。

Open棟梁の動的パラメタライズド・クエリ

特徴

  • ADO.NETのラッパーライブラリ。
  • ADO.NETをラップし、動的SQL編集機能を同梱。

適合するシステム・アプリケーション

  • SQL編集処理が複雑になるエンプラのドメインで使える。
    • SQL定義をパラメタセットによって編集したい(S2DaoやiBATISのように)。
    • メソッド(=LINQのメソッド ベースのクエリ構文(メソッドチェーンやラムダ式))
      でクエリ編集という方式は、エンプラのドメインに必要とされる柔軟性が足りない。

ORM系

  • 基本的にSQLを使用せず、概念スキーマに準拠したオブジェクトにデータをストアする。
  • プログラム側のデータの持たせ方が「2次元表」 vs Bean(POCO)と、根本的に異なる。

Entity Framework

Entity Frameworkは高機能で複雑なため、
ORM自体の問題と、切り分けが難しい別の問題を持っている。

特徴

以下のような、3つの開発スタイルがある。

  • DBファースト
    • DB設計者(DA、DBA)の設計したDBを使用する。
    • 基幹系システムやビジネス・アプリケーションではコチラを使用する事が多いと思われる。
  • コードファースト
    • Entityの設計がDBスキーマに反映される。既存DBにも適用可能。
    • 以下の様なシステム・アプリケーションではコチラを使用する事があると思われる。
      • クライアント・アプリケーション
      • プロトタイプ・モックアップのデータアクセス部の開発
      • SQLを駆使しない、データアクセスが比較的簡単なシステム・アプリケーション

適合するシステム・アプリケーション

  • データをオブジェクトとして保持しセーブ・ロードを繰り返すようなシステム(オンライン・ゲームなど)。
  • 単純なユーザ・ストアにアクセスして、ユーザ・データを更新するようなシステム。
  • 1ページ、1テーブル(ビュー)&1トランザクション的な、割りきった作りのシステム。
  • 例えば、クライアント・アプリケーションや、前述のシステム・アプリケーションに合致しないサービスなど。

参考

以下が参考になる。

Dapper

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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-09-18 (火) 11:12:50 (30d)