- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-戻る
--[[データアクセスのいろいろ]]
--[[VS系コンテンツ]]
* 目次 [#r017928e]
#contents
*概要 [#h777e793]
[[ADO.NET>#d8190ea9]]、[[Entity Framework>#ufc012af]]、[[Dapper>#cb059443]]、その他の選択肢のどれを選ぶべきか？~
トレードオフがあるので、新しい技術を使っておけばイイという訳には行かない模様。
*[[生のデータプロバイダ系（ADO.NET）>ADO.NETデータプロバイダ]] [#d8190ea9]
SQLを使用して、二次元表形式の論理データを自由に取得できる。
**DataReader, DataSet [#a3095c41]
***特徴 [#eefba248]
Bean(POCO)にORMではなく、論理データ独立な二次元表（DataSet、DataTable）を使用できる。
-DataAdapter は DataSet オブジェクトとデータ ソース間のブリッジとして機能する。
-DataSet の機能が必要ない場合は、DataReader を使用したほうが性能が向上する。
-[[非接続型データアクセス>ADO.NET]]を実行する場合はDataSetを使用する。
--データをローカルにキャッシュし操作する場合。
--サーバーで取得・更新、クライアントで編集等、~
物理境界を超えてデータを持ち回って処理を行う場合。
--Windows フォーム コントロールとの連結し、対話的に編集をする場合など。
DataSet
├DataRelationCollection
├ExtendedProperties
└DataTableCollection
└DataTable
├DataColumnCollection─DataColumn─ExtendedProperties
├PrimaryKey
├Constraints
├ChildRelations
├ParentRelations
├ExtendedProperties
├DataView
├DataRowCollection─DataRow
***Bean(POCO)変換 [#x6e0b188]
[[実装は、それ程、難しくない。>AutoMapper#ob11e4cd]]
***適合するシステム・アプリケーション [#w66b9a13]
-情報系システム
--多種・多様なビュー（二次元表形式の論理データ）にアクセスする。
--参照先のテーブルや取得するカラムを動的に変更するようなシステム。
-基幹系システム
--複雑なデータクセスに対応する柔軟性と、~
大量データの処理に対応するパフォーマンスを両立させる必要があるシステム。
--参照したビュー（二次元表形式の論理データ）を元に更新処理を行なうシステム。
**[[DataAdapter]], [[TableAdapter]] [#j926d919]
ORM的なソリューションだが、~
今となっては、中途半場で、あまり利用されていない。
***特徴 [#i7223bca]
-[[ADO.NET]]のラッパーライブラリ。
-[[非接続型データアクセス>ADO.NET]]のDataSetが前提。
***適合するシステム・アプリケーション [#g2e9fc1f]
JIONなどもサポートしているもよう（下記参照）なので、~
頑張れば、情報系システム、基幹系システムへの応用も可能と思われる。
-参考
--Join を使用して TableAdapter を更新する (c#) | Microsoft Docs~
https://docs.microsoft.com/ja-jp/aspnet/web-forms/overview/data-access/advanced-data-access-scenarios/updating-the-tableadapter-to-use-joins-cs
**Open棟梁の[[動的パラメタライズド・クエリ>https://opentouryo.osscons.jp/index.php?%E5%8B%95%E7%9A%84%E3%83%91%E3%83%A9%E3%83%A1%E3%82%BF%E3%83%A9%E3%82%A4%E3%82%BA%E3%83%89%E3%83%BB%E3%82%AF%E3%82%A8%E3%83%AA]] [#p32d32e5]
***特徴 [#q9861167]
-[[ADO.NET]]のラッパーライブラリ。
-[[ADO.NET]]をラップし、動的SQL編集機能を同梱。
***適合するシステム・アプリケーション [#ee069a8d]
-SQL編集処理が複雑になるエンプラのドメインで使える。
--SQL定義をパラメタセットによって編集したい（S2DaoやiBATISのように）。
--メソッド（＝LINQのメソッド ベースのクエリ構文（メソッドチェーンやラムダ式））~
でクエリ編集という方式は、エンプラのドメインに必要とされる柔軟性が足りない。
*ORM系 [#q166dadc]
-基本的にSQLを使用せず、概念スキーマに準拠したオブジェクトにデータをストアする。
-プログラム側のデータの持たせ方が「2次元表」 vs Bean(POCO)と、根本的に異なる。
**[[Entity Framework]] [#ufc012af]
[[Entity Framework]]は高機能で複雑なため、~
ORM自体の問題と、切り分けが難しい別の問題を持っている。
***特徴 [#tb44de0f]
以下のような、[[３つの開発スタイル>Entity Framework#m1aabfea]]がある。
-[[モデルファースト>Entity Framework#e8fd5f15]]
--[[Entity Framework]]の基本的な使い方。
-[[DBファースト>Entity Framework#k0847c21]]~
--DB設計者（DA、DBA）の設計したDBを使用する。
--基幹系システムやビジネス・アプリケーションではコチラを使用する事が多いと思われる。
-[[コードファースト>Entity Framework#rcec17e4]]
--Entityの設計がDBスキーマに反映される。既存DBにも適用可能。
--以下の様なシステム・アプリケーションではコチラを使用する事があると思われる。
---クライアント・アプリケーション
---プロトタイプ・モックアップのデータアクセス部の開発
---SQLを駆使しない、データアクセスが比較的簡単なシステム・アプリケーション
***適合するシステム・アプリケーション [#e851970c]
-データをオブジェクトとして保持しセーブ・ロードを繰り返すようなシステム（オンライン・ゲームなど）。
-単純なユーザ・ストアにアクセスして、ユーザ・データを更新するようなシステム。
-１ページ、１テーブル（ビュー）＆１トランザクション的な、割りきった作りのシステム。
-例えば、クライアント・アプリケーションや、[[前述のシステム・アプリケーション>#w66b9a13]]に合致しないサービスなど。
***参考 [#x9c2bdb1]
以下が参考になる。
-[[Entity Framework の懸念]]
-[[Entity Framework の調査]]
**[[Dapper]] [#cb059443]
[[Dapper]]は単純な分、ORMの良さや悪さを分析し易い。
***特徴 [#i5375712]
-厳密に言えば、ORMではなく、Micro-ORM（DataMapperとかTableMapper）。
-SQL（の入出力パラメタ）と、Bean(POCO)の間のマッピングを行う。
***感想 [#f04a645b]
[[Dapperを使って認証基盤のユーザストアの永続化を実装してみた>https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/Models/ASPNETIdentity/Entity/UserStore.cs]]感想。
-（[[Dapper]]は正確にはORMではないが、同様に、）複雑なデータアクセスは弱い。
-ただしRDBMSをNoSQLやX.500などのストアとコンパチにするような実装の場合は、~
オブジェクト <---> ストア的な実装が必要とされるので、用途次第で適合する可能性はあると言える。
***適合するシステム・アプリケーション [#ve277fa2]
以下の様なケースでは、[[Dapper]]がイイのでは無いかと考える。
-データストア、データアクセスが単純なケース。
-サーバーをJSON吐く土管化するようなケース。
-RDBMSをNoSQLやX.500などのストアとコンパチにするようなケース
*分析 [#z962fdba]
データアクセスのフレームワークにも、
データアクセスのフレームワーク、其々に、
-[[生のデータプロバイダ系>#mf0793cf]]はSQL編集処理の柔軟性が高いが、
-[[ORM系>#od8163b5]]は、コーディングが容易化されているが、SQL編集処理の柔軟性が低い。~
（Bean(POCO)側が静的なので、SQL側だけ動的化するインターフェイスを実装できない）
などのトレードオフがある。
このため、アプリケーションの特性によって、~
そのデータアクセスのフレームワークが適合するか？しないか？がある。
※ 例えば、基本的なORM実装では、オブジェクト操作と永続化操作は切り離されており、~
オブジェクトに対する変更を無造作に更新するため、未更新の列なども更新対象になる。~
（基本的に、未更新列を更新対象から外すなどの、きめ細かな操作はしない。）
*参考 [#tb2cf9a3]
-Entity Framework VS LINQ to SQL VS ADO.NET with stored procedures? - Stack Overflow~
http://stackoverflow.com/questions/2698151/entity-framework-vs-linq-to-sql-vs-ado-net-with-stored-procedures
-Hibernateはどのようにして私のキャリアを破滅寸前にしたか | To Be Decided~
https://www.kaitoy.xyz/2017/02/23/how-hibernate-ruined-my-career/
----
Tags: [[:データアクセス]], [[:.NET開発]], [[:ADO.NET]], [[:Entity Framework]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
