1

たとえば、次のことを考慮してください。

public interface IStaff
{
    FullName name { get; set; }
    EMailAddress email_address { get; set; }
    SocialInsuranceId ssn { get; set; }
    PositiveInt age { get; set; }
    Address home_address { get; set; }
}

一部のユーザーの場合、ビューモデルはとのみを必要nameとしemail_addressます。ssn他の人は、それらのプロパティに加えて、、ageおよびを含むビューモデルを持っているかもしれませんhome_address。ビューが取得する統計家もいるとしましょageうhome_address。

IStaffBasicこれで、これを、、IStaffDetailsおよびインターフェイスの継承に分割してIStaffStats、特定のビューモデルのAPIを適切なプロパティに制限することができます。

ただし、このエンティティがネットワークを介してデータサービスから取得される場合でも、追加の詳細が含まれているため、発生してはなりません。


したがって、 （A）これらのバージョンごとに完全に異なるエンティティタイプを作成し、タイプごとに多くの追加のほぼ重複するクエリ操作でサービスレイヤーAPIをいくらか汚染するか、
（B）常にStaffエンティティを返す方が良いでしょうか？ 1）サービスでの承認チェックに基づいて設定された除外プロパティを使用してサービスからそれらを返しnull、（2）上記のようにビューモデル内で制限されたインターフェイスを使用するか、
（C）私が使用していない非常にエレガントなパターンまたはソリューションを使用します検討しましたが、それについてあなたは私に言うつもりです。

オプションAは、ビューモデルレベルではよりクリーンに見えますが、サービスAPIは厄介なものになります。オプションBは、サーバーでのエンティティの処理を複雑にするようですが、オープンクローズの原則をより適切に順守します。

考え？

4

1 に答える 1

1

投影は進むべき道です-オプションAとBを組み合わせてください。

ORMは単一のエンティティタイプとのみ対話する必要があるStaffため、マッピングやクエリなどの単一のセットを維持（および拡張）するだけで済みます。

IStaffBasicただし、各セキュリティシナリオ（ 、IStaffDetailsなど）に適したさまざまなクラスを作成Staffし、それらにインスタンスを投影し、投影されたオブジェクトをネットワーク経由で返します。

一部のORMは、フレームワーク機能としてプロジェクションをサポートしていますが、必要に応じて、サービスレイヤーで手動で行うことができます。

于 2010-02-02T16:33:57.107 に答える