「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -戻る --[[データアクセスのいろいろ]] --[[VS系コンテンツ]] * 目次 [#r017928e] #contents *概要 [#h777e793] [[ADO.NET]] 、 [[Entity Framework]] 、[[その他の選択肢>#g3eea0bc]]のどれを選ぶべきか? *分析 [#z962fdba] データアクセスのフレームワークにも、 -[[生のデータプロバイダ系>#mf0793cf]]はSQL編集処理の柔軟性が高いが、 -[[ORM系>#od8163b5]]はSQL編集処理の柔軟性が低い。 というトレードオフがある。 このため、アプリケーションの特性によって、~ そのデータアクセスのフレームワークが適合するか?しないか?がある。 *[[生のデータプロバイダ系(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 ***適合するシステム・アプリケーション [#w66b9a13] -情報系システム --多種・多様なビュー(二次元表形式の論理データ)にアクセスする。 --参照先のテーブルや取得するカラムを動的に変更するようなシステム。 -基幹系システム --複雑なデータクセスに対応する柔軟性と、~ 大量データの処理に対応するパフォーマンスを両立させる必要があるシステム。 --参照したビュー(二次元表形式の論理データ)を元に更新処理を行なうシステム。 **[[DataAdapter]], [[TableAdapter]] [#j926d919] ***特徴 [#i7223bca] -[[ADO.NET]]のラッパーライブラリ。 -[[非接続型データアクセス>ADO.NET]]のDataSetが前提。 ***適合するシステム・アプリケーション [#g2e9fc1f] ORM的なソリューションだが、あまり利用されていない。 **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を使用せず、概念スキーマに準拠したオブジェクトにデータをストアする。 **[[Entity Framework]] [#ufc012af] ***特徴 [#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トランザクション的な、割りきった作りのシステム。 -例えば、クライアント・アプリケーションや、[[前述のシステム・アプリケーション>#vc47ddae]]に合致しないサービスなど。 -補足~ エンタープライズ分野のビジネス・アプリケーションでは、~ 「RDBMSの複数テーブル&ビューを参照して、テーブル単位に更新する。」~ という処理になりがちで、この処理がそもそもORMに適合しない。 **[[Dapper]] [#cb059443] ***特徴 [#i5375712] -厳密に言えば、ORMではなく、Micro-ORM(DataMapperとかTableMapper)。 -SQL(の入出力パラメタ)と、Bean(POCO)の間のマッピングを行う。 ***適合するシステム・アプリケーション [#ve277fa2] 以下の様なケースでは、[[Dapper]]がイイのでは無いかと考える。 -データストア、データアクセスが単純なケース。 -サーバーをJSON吐く土管化するようなケース。 *参考 [#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]]