マイクロソフト系技術情報 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

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

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

DataAdapter, TableAdapter

ORM的なソリューションだが、

特徴

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

今のとなっては、中途半場で、あまり利用されていない。

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

特徴

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

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

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

ORM系

基本的にSQLを使用せず、概念スキーマに準拠したオブジェクトにデータをストアする。

Entity Framework

特徴

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

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

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

  • データをオブジェクトとして保持しセーブ・ロードを繰り返すようなシステム(オンライン・ゲームなど)。
  • 単純なユーザ・ストアにアクセスして、ユーザ・データを更新するようなシステム。
  • 1ページ、1テーブル(ビュー)&1トランザクション的な、割りきった作りのシステム。
  • 例えば、クライアント・アプリケーションや、前述のシステム・アプリケーションに合致しないサービスなど。
  • 補足
    エンタープライズ分野のビジネス・アプリケーションでは、
    「RDBMSの複数テーブル&ビューを参照して、テーブル単位に更新する。」
    という処理になりがちで、この処理がそもそもORMに適合しない。

Dapper

特徴

  • 厳密に言えば、ORMではなく、Micro-ORM(DataMapper?とかTableMapper?)。
  • SQL(の入出力パラメタ)と、Bean(POCO)の間のマッピングを行う。

感想

Dapperを使って認証基盤のユーザストアの永続化を実装してみた感想。

  • Dapperは正確にはORMではないが、)
    ORMはエンプラ業務ドメインのRDBデータアクセス的には正直微妙。
  • プログラム側のデータの持たせ方が2次元表 vs ORMと、根本的に異なる。
  • ただしNoSQLやX.500などユーザ・ストアを可変にするような実装の場合、
    オブジェクト <---> ストア的な実装が汎用的で且、必要とされるので、用途次第。

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

以下の様なケースでは、Dapperがイイのでは無いかと考える。

  • データストア、データアクセスが単純なケース。
  • サーバーをJSON吐く土管化するようなケース。

参考


Tags: :データアクセス, :.NET開発, :ADO.NET, :Entity Framework


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-02-05 (月) 17:40:36 (18d)