ADO.NET Entity FrameworkおよびLINQ to SQLについての最大の不満の1つは、変更のトラッキングをサポートしていなかったことである。オブジェクトを変更し、データベースに保存することができ るが、コンテキストオブジェクトに接続されている場合のみである。一度コンテキストオブジェクトが範囲外にいくと、データベースのように、接続は非常に迅 速であるべきだが、基本的にデータオブジェクトは読み取り専用になる。その変更を書き戻すために、新たなコンテキストにそれらを再添付する良い方法はな い。
Microsoftがこの対応を拒んでいるが、まったく訳が分からない。データプロジェクト内部に変更のトラッキングを追加するのではなく、ほとんどのORMライブラリがPOCOまたは「Plain Old C# Objects」により一層重点を置いている。
Entity Framework Designブログ(リンク)では、Microsoftの3人のデベロッパが有名なデータベースアクセスメソッドを試した。最初は、ADO.NET DataSetである。変更をデータベースに記述することができる。ADO.NET DataSetの 「問題」を4つ挙げているが、どれもたいして意味がない。非トラステッド境界全体で、変更を送信することに焦点を当てているが、たいして意味がない。デー タベースアクセスやORMライブラリは、データを浄化するように意図されているが、それはアプリケーション自体によって処理されるべきである。
次は、DTOまたはData Transfer Objectの出番である。「オブジェクトにすべてのデータを入れたので、それを扱うことができる」と言える。これは今ある議論とは実に関係がないが、何を考えているかが分かる。
次にRESTについて簡単に述べている。Entity Frameworkチームが自分たちは何を構築しようとしているのかを完全に分からなくなっていると判断できる。「目標」のもとで、以下のように述べている。
Entity Frameworkに対するN層の改善で、DataSetと同様の問題空間に取り組みたいが、それに関わる基本的な問題は避けたい。
理想としては、幅広いアーキテクチャで、ソリューションを構築しているデベロッパに訴えるビルディングブロックを提供したい。たとえば、DTO支持者に制 御を提供したいが、こんにちより単純なシナリオエクスペリエンスに対処しようとしているものの痛みのレベルを同時に少なくする。
これで問題がはっきりした。Entity Frameworkは別のORMにはなりたくないわけで、すべてのものにとって役立つものになることを望んでいる。これまで何度もみてきたように、このアプローチはたいてい誰のためにもならない。チームによるこの発言を検討する。
これら2つの他に、グラフの変更の興味深い汎用表現があるが、一般的にそれらは同じようなデメリットがある。ソリューションを提供すると、ほとんどの複雑なシナリオや高度なパターンが必要とするコントロールレベルをユーザに提供しない。
以下のように続く。
Entity Frameworkは、N層アプリケーションで表示された一連の変更won’t define its own unique representation for the set of changes represented in an N-Tier application. その代わり、幅広い表記の使用を推進する基本的なビルディングブロックAPIを提供する。
変更のセットを巧みに操作するという問題に対して完全なソリューションを提供することができないため、デベロッパには何も提供しない。コンテキスト外でデータ操作する場合、デベロッパはEntity Frameworkの上に独自のORMを構築する必要がある。
記事の残りは、新たなAPIを使用して基本的な変更のトラッキングを実行する方法を述べたいくぶん冗長的な例である。これにはIEntityWithChangesのようなインターフェイスを作成したり、GetEntityStateの ような手書きのメソッドを使用してこれをマッピングしたり、コンテキストオブジェクト、エンティティ状態名、エンティティグラフおよびエンティティ状態 マップを取るメソッドで両方を使用することが含まれる。これは単に変更の保存のためであることを心に留めておく必要がある。そもそもどうにかして変更をト ラックしなければならない。
Ayende Rahien氏は、それをどうおこなうべきかを説明している(リンク)。
NHibernateを使用して、これをおこなうには、以下のようにする。
session.Merge( entityFromPresentationLayer );
Frans' LLBLGenは、非常に似た機能をサポートする。つまり、これをおこなうのはデータアクセスフレームワークであり、デベロッパではない。
Frans Bouma氏(リンク)といえば、以下のようにこの状況についてまとめている。
データセットを使用しているデベロッパは、EFが正しい方法だということをどうやって納得するのだろうか?最初から、DataSetが この問題を解決した時、 それは言うまでもないが、多くの競合O/Rマッパーフレームワークはどうか?このすべてに関する中心的な問題は、フレームワークデベロッパの観点からフ レームワークを設計するという過ちだと考える。つまり、フレームワークを記述する場合、2種類の「正」がある。フレームワークデベロッパの観点とフレーム ワークユーザの観点である。重大なミスは、これらの2通りの「正」が本当は同じであるという前提にある。さらに悪いことには、フレームワークデベロッパの 「正」という概念が実際はフレームワークユーザが望んでいるものだと仮定していることである。