「[[マイクロソフト系技術情報 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] 以下のような、[[3つの開発スタイル>Entity Framework#m1aabfea]]がある。 -[[モデルファースト>Entity Framework#e8fd5f15]] --[[Entity Framework]]の基本的な使い方。 -[[DBファースト>Entity Framework#k0847c21]]~ --DB設計者(DA、DBA)の設計したDBを使用する。 --基幹系システムやビジネス・アプリケーションではコチラを使用する事が多いと思われる。 -[[コードファースト>Entity Framework#rcec17e4]] --Entityの設計がDBスキーマに反映される。既存DBにも適用可能。 --以下の様なシステム・アプリケーションではコチラを使用する事があると思われる。 ---クライアント・アプリケーション ---プロトタイプ・モックアップのデータアクセス部の開発 ---SQLを駆使しない、データアクセスが比較的簡単なシステム・アプリケーション ***適合するシステム・アプリケーション [#e851970c] -データをオブジェクトとして保持しセーブ・ロードを繰り返すようなシステム(オンライン・ゲームなど)。 -単純なユーザ・ストアにアクセスして、ユーザ・データを更新するようなシステム。 -1ページ、1テーブル(ビュー)&1トランザクション的な、割りきった作りのシステム。 -例えば、クライアント・アプリケーションや、[[前述のシステム・アプリケーション>#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/CommonLibrary/Data/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/ -Java ORマッパー選定のポイント #jsug~ https://www.slideshare.net/masatoshitada7/java-or-jsug ---- Tags: [[:データアクセス]], [[:.NET開発]], [[:ADO.NET]], [[:Entity Framework]]