![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
Entity Frameworkを利用する上での懸念をまとめてみた。
全体的に、
から
などがブラックボックス化されているため、
Entity Framework自体の仕様に精通していないと、
ハイパフォーマンスな実装をすることができない。
という問題がある。
foreachでデータアクセスした場合など、
検索SQLが検索キーや射影の列名を指定しないので性能的に問題になる。
以下の様な手段により、処理対象のEntityをメモリに起こしてしまう。
この場合、ToArray?()メソッドを使って、はじめに結果を確定させる。
var YYYYYs = context.YYYYYs.ToArray();
この場合、Load()メソッドを使って、DbContext?内にデータをキャッシュさせる。
context.YYYYYs.Load();
この後、context.YYYYYsにアクセスしてもSQLは実行されない。
ライブラリがいくつかある。（非 MS 製、NuGet からインストール可能）
となる。
処理される場所だけでなく、処理結果が異なることがある。
context.YYYYYs.OrberBy(x => x.Name).ToArray()
context.YYYYYs.ToArray().OrderBy(x => x.Name)
DBMSの照合順序などの関係により、
処理される場所によって、ソート（OrberBy?）順が異なるためである。
AsNoTracking?()メソッドでCollectionを取得すると、
Entity Statesのトラッキングをしなくなる。
var YYYYYs = context.YYYYYs.AsNoTracking().ToArray();
これにより、使用するメモリ量を削減できる。
コードファーストのデータモデルクラスの変更をもとに、
既存のデータを残したままデータベースのテーブルを変更する機能。
コードファーストでは規約に基づいてEntityとDatabaseを紐付ける。
属性による規約
| 項番 | 属性名 | 説明 |
| １ | Table | EntityとTable間のマッピング |
| ２ | Column | EntityのPropertyとTableのColumn間のマッピング |
| ３ | ComplexType? | Entityの複数のProperty(Properties)とTable間のマッピング ComplexType?の複数のProperty(Properties)は、別のTableに切り出される。 |
| ４ | Key | EntityのPropertyを対応するTableのPrimaryKey?に設定する。 |
| ５ | Required | EntityのPropertyに対応するTableのColumnをNOT NULLに設定する。 MVCのModelMetadata?として検証処理に使用される。 |
| ６ | MaxLength? | EntityのPropertyに対応するTableのColumnのデータ長を設定する。 MVCのModelMetadata?として検証処理に使用される。 |
| ７ | Index | EntityのPropertyに対応するTableのColumnを使用した非クラスタ化・インデックスを作成する。 |
| ８ | NoMapped? | EntityのPropertyをDatabaseにマップしない。 |
その他、DbContext?を継承したContextのコンストラクタで接続文字列を決定できる。
Fluent APIによる規約
エンティティ間の関連（アソシエーション）を表す。
基幹系システムでは以下の理由でミスマッチと判断されることが多い。
概念モデルに対してプログラミングを採用している。
SQLが、LINQ to Entityのエンジンに生成される形であり、
また、内部実装とその動作がブラックボックスになっているため（※１）
それらが明確にならないと設計、チューニング、問題分析などが困難。
従って（特に日本の）エンタープライズ・アプリケーションでは敬遠されている。
これは、JavaのJava8でJPAでHibernateでJinqが敬遠されるのと≒。
Tags: :.NET開発, :データアクセス, :ADO.NET, :Entity Framework, 性能?
