まずは階層構造。まずはオブジェクトそのものを解説して欲しいのですが、そういう発想は無いようです。まともに設計されたオブジェクトは１行で説明できる、はずなんですがね。オブジェクトの説明前に使い方の説明に入るのはオブジェクト指向的にはどうよ、というところです。図と説明から判断すると、EntityClientデータプロバイダが Entity Framework用のデータアクセスクラス（というかほとんどインターフェース階層でしょうね）で、それをドライバとして使う形で Entity FrameworkでのオブジェクトデータマッピングサービスがObject Services という名前（総称）で実装されているという感じでしょう。で、アプリケーションからのインターフェースは、
- LINQ to Entities - 名前の通りLINQ経由でアクセスするためのインターフェース
- Entity SQL - これは本来的にはEntityClientデータプロバイダインターフェースでしょう
- QueryBuilder - は謎ですね。後で解説されるのでしょうが雰囲気的にはEntity SQLを構築するのでしょうね。
の３系統があるという構造のようです。
Entity SQLを Entity Framework用のSQLライクな言語、といっていますが、本来の目的はEntityClient データプロバイダに対するコマンドのようです。言語からは単なる文字列として扱われるため、シンタックスチェック等が効きません。ですから余程のことがなければ直接使ってはいけない機能のはずです。というわけでここはさくっと飛ばしてしまいましょう。
QueryBuilderは一見 LINQ のメソッド構文風ですが、条件その他に文字列が残っています。目的が判りにくいですね。ひょっとするとLINQ to Entities のメソッドを構成するためのサポートインターフェースかも知れません。これも使う必然性のなさそうなインターフェースですので、サクっと読み飛ばします。
LINQ to Entities の場合には、APIはLINQそのものです。LINQがデータを（条件指定で）列挙するための共通インターフェースになっているので、下位層がなにであろうとインターフェースは変わりません。ということで、LINQ知っていればここもさくっと読み飛ばしてOKということです。考えてみるとLINQへのプロバイダインターフェースが提供されているとアプリケーションからは何も特別視しなくて済むようになるわけですね。しかも各種のシンタックスチェック付きで。こうやってみるとLINQはすごい技術ですね。
と遅延読み込みの話題が出ていますが、きっとLINQからアクセス可能、だけで終わってしまって他に書くネタが無くなったのでいれたんじゃないですかね。確認してみましたが確かに.NET3.5でORマップしたアクセスオブジェクトには無いプロパティでした。ただ実際に使うには色々と問題が多い機能なのでそれなりに注意を、というところです。まあ、実際のデータによりますが、ここのサンプルで扱っているカテゴリデータでしたら遅延アクセスするよりプリロードしておいたほうがいいでしょうね。
データ保存は前の回でも簡単にやっていますが、Entitiesのコレクションへのデータオブジェクトの追加（AddObject）と、コンテキストに対する変更データの保存（SaveChanges）によって行ないます。ただ、SaveChangesは変更された項目毎にSQLを発行するような構成になるので、大量データの操作を行なう場合には性能上の問題が出てくる可能性があります（実際にはバッチ系の操作以外で大量データ更新が行なわれることは少ないはずですが）。
このような状況への対処のためにネイティブSQL文をコンテキスト経由で実行させる機能（ExecuteStoreCommand）が用意されています。なお、記事では.NET 4から導入された機能、と書かれていますが、 .NET 3.5 にもメソッド名は異なっていますが同等機能（ExecuteCommand）が存在しています。
まとめのところでLINQ経由でのアクセスを推奨しています。実際、O/Rマップ自体、LINQのため、と考える方がいいでしょう。検索系のアクセスに関しては便利さからもシンタックスチェックがかかる点からもLINQを使うのがベストでしょう。
0 件のコメント:
コメントを投稿