ほとんどのMVVMアプリケーションでは、このアーキテクチャを持っているでしょう：私は最近、バリアントespousingされている
View -> ViewModel -> Model -> Repository
：
View -> ViewModel <- Presenter -> Model -> Repository
（A - > Bは "AがBを知っている" を意味しますが、BをA.について知りません）
リポジトリについて知っているのは、ViewModelではなくModelだけです。あなたのモデルはドメインエンティティだけでなく、ビジネスロジックも格納しなければなりません。もちろん、あなたのビジネスロジックをサポートするために持っているユーザーストーリーの一つは、私が電話するよ何かがあるMemberEditTask：可能な選択肢のリスト（とは、それらの一つであったことを確認するため、このロジックのすべてがあなたのモデルに属する
public class MemberEditTask
{
private readonly Member _member;
public MemberEditTask(Member member, IRepository repository)
{
this._member = member;
this.StatusChoices = repository.GetPossibleMemberStatuses(member);
}
public ReadOnlyCollection<MemberStatus> StatusChoices { get; private set; }
public MemberStatus Status
{
get { return this._member.Status; }
set
{
if(!this.StatusChoices.Contains(value))
{
throw new ArgumentOutOfRangeException();
}
this._member.Status = value;
}
}
}
実際に選択される）はビジネスロジックによって定義されます。 MemberEditTaskを消費する他のものを想像することもできます。たとえば、FTPサーバーにアップロードされたファイルに応答してメンバーを編集するサーバー上で実行される自動プロセス、またはバックグラウンドプロセス（特定の時間が経過した後、 ）。これらのすべてのものは同じビジネスルールを実行する必要があるため、ViewModelではなくすべて共通でなければなりません。
だから、そのクラス与えられた、のViewModelクラスは次のようになります。ただNotifyAllPropertiesChangedはPropertyChangedを高めるためにリフレクションを使用していますViewModelBaseの保護された方法があることを信じて、非常に単純な利便性として、この場合、
public class MemberEditViewModel : ViewModelBase
{
private readonly MemberEditTask _task;
public MemberEditViewModel(MemberEditTask task)
{
this._task = task;
}
public IEnumerable<MemberStatus> StatusChoices
{ get { return this._task.StatusChoices; }
public MemberStatus Status
{
get { return this._task.Status; }
set
{
this._task.Status = value;
NotifyAllPropertiesChanged();
}
}
}
イベントすべて ViewModelのパブリックプロパティ。 :)それはもちろん残虐ですが、それはより重要なポイントにドライブします...
これは、この場合、MemberEditViewModelが不要なので、ほとんど馬鹿げた例です。ビューが唯一の設定である場合Statusプロパティ変更イベントを発生させる必要はありません！もちろん、現実の世界では、より多くの特性を持ち、相互作用があります。 ViewModelが存在する理由は、View関連のプロパティが変更されたときにコンシューマに通知することです。これは、Modelが実行しないものです（私の意見ではありません）。 （ViewModelには、アニメーションなどをサポートするビュー固有の特別なロジックもあります）
質問に戻る...リポジトリがモデルによって使用されるサービスであるため、MemberRepositoryがステータス取得を実行するかどうかは、ViewModelの観点からは関係ありません。モデルは、ViewModelによって使用されるサービスです。タスク/ワークフロー/プロセスのモデルを作成し、ステータスオプションのリストを公開します。
申し訳ありませんが、それは長らく残っていました。