0

これは明らかに何度も議論されてきたトピックですが、ここでの私のアプローチの角度は少し異なります. 私が理解している限りでは、STE は POCO と見なされます (決して EF dll に関連付けられていません)。独自の変更追跡を処理するための追加の「もの」が内部にあるだけです。次のアプリケーション層を想定しています。

Proj.Web
Proj.Business
Proj.Model
Proj.DataAccess

必須ではなく、2 層のセットアップで実行していると仮定するとlazy loading、STE と POCO の使用に違いはないと私は理解しています。私たちは Web 上にいて、接続されていない環境であるため、選択肢は で追加の SQL クエリを実行するPostbackか、エンティティをアタッチして、必要に応じてプロパティを変更するように設定する必要があります。繰り返しますが (間違っている場合は訂正してください)、コードは同じように見えます。

簡単な例を考えてみましょう。Web フォーム アプリケーションでポストバックを処理しています。

Person p = PersonManager.GetById(2); //we use the "requery" method
PersonManager.Update(p);

//If we dig into PersonManager.Update() we'll see the following:
PersonRepository.ApplyChanges(p); //we're assuming STEs are used so this API is available
PersonRepository.SaveChanges();

後で、Proj.Business と Proj.Web の間に WCF トランスポート層を導入して、アーキテクチャを 3 層に昇格するように求められたとします。これを Proj.Services と呼びましょう。最初から STE を使用していた場合、はるかに優れた状況にあるのではないでしょうか? ビジネス レイヤーやリポジトリを変更することなく、呼び出しをビジネス レイヤーに転送するだけで済みます。

PersonService.Update(Person p)
{
    PersonManager.Update(p);
}

たとえば、POCO を使用している場合 (スナップショットを想定してみましょう)、このエンティティがコンテキストに既に存在するかどうか (2 層を実行している場合) を確認し、存在しない場合 (3 -tier) それをアタッチし、そのプロパティを変更済みに設定します。将来的に 3 層ソリューションが必要になるかどうかわからない場合は、さらに多くの作業が必要になるようです。一方、最初から STE に対してコーディングしていた場合、余分に不要な (実際には何も害を与えない) コードは、ApplyChanges() の呼び出しだけです。それ以外の場合は、何も失うことはないと思います (遅延読み込みは必要ないと仮定します)。この件についてどう思いますか。

4

2 に答える 2

2

STE は Web アプリケーションにはあまり適していません。彼らの問題は、彼らがどのように働くかです：

  • STE をロードしてコンテキストを閉じる
  • STE で提供されたデータを操作する
  • データを STE にプッシュ バックする
  • STE からの変更を新しいコンテキストに適用すると、すべての変更がオブジェクト グラフに渡されます。

それは素晴らしい機能のように思えますが、おそらくそうではありません。ASP.NET の場合、ほとんどの場合、次のことを意味します。

  • 最初の取得リクエストのデータをロードし、STE をどこかに保存します
  • 次の更新リクエストでデータを取得し、保存された STE にデータを入力します

STE をセッション状態またはビュー状態に保存する必要があるため、これはひどいことです。

あなたが説明したアプローチは、別の方法で機能します。最初のリクエストからSTEを保存しませんが、更新リクエストでサービスを2回呼び出します

  • 新しい STE を取得するのは初めて
  • 更新された STE を戻す 2 回目

多くのデータ（オブジェクトグラフ）を転送できる追加のリモート呼び出しがあり、その後オブジェクトグラフ全体を戻すため、これはあまり良くありません。

明らかに、両方のアプローチがいくつかのアーキテクチャ上のアイデアに違反しています

  • Web アプリケーションはできるだけ状態を少なくする必要があるため、不要な状態を Web アプリケーションに保存しないでください。
  • 非常にコストがかかるため、リモート呼び出しを最小限に抑えます + 転送されるデータの量を、実際に渡さなければならないデータに減らします

リモート シナリオをはるかに簡単にすることができますが、独自のコストがかかります ( .NET-.NET ソリューションです)。リモート シナリオがない場合に使用する理由は 1つではありません = STE を使用する必要がない場合は、単純に使用しないでください。さらに、実装に問題があるという報告もあります。ユーザーの声では、それらがまったく機能しないという提案さえ見つけることができます。

于 2011-07-18T21:15:35.730 に答える
0

Ladislav Mknka は、STE を使用しない理由についていくつかの優れた点を指摘しましたが、この質問に対する万能の答えは実際にはないようです。たとえば、現在の 2 層プロジェクトでは、それらは不要かもしれません。ただし、将来的には、このプロジェクトの管理部分に Silverlight を利用することを強く検討しています。これは、モデルとリポジトリ用に 1 つのプロジェクトがあることを意味し、うまくいけば両方の上位層プロジェクトで利用されることになります。したがって、1 つは 2 層で実行され、もう 1 つは 3 層で実行されます (Silverlight にはサービスが必要なため)。私が知る限り、STE は「接続された」環境でスナップショット POCO と同じように動作するため、2 層アプリで STE をそのまま使用しても、多くを失うことはありません。ただし、3 層の Silverlight ピースを追加すると、非常に便利であることが証明される可能性があります。

この問題を解決するには明らかに他の方法があります。特定のエンティティが追跡されているかどうかを判断し、その決定に基づいて必要なタスクを実行する方法でリポジトリを作成することもできます。開発労力の面ではるかにコストがかかります。時間が経てば分かると思います。

于 2011-08-07T19:55:52.933 に答える