1

ViewModel、モデル、MVVM アーキテクチャの問題。

むかしむかし、次のようにモデル クラスを定義していました。

public class Person
{
  public string FirstName;
  public string LastName;
}

数年後、次のようにモデル クラスを定義する方がよい考えであることがわかりました。

public class Person
{
  private string firstName;
  private string lastName;

  public string FirstName {get{ return firstName;} set{ return firstName; } }
  public string LastName  {get{ return lastName; } set{ return lastName;  } }
}

なぜ..一般的に、より汎用性が高いためです。例:

public class Person
{
  private string firstName;
  private string lastName;

  public string FirstName {get{ return firstName;} private set{ return firstName; } }
  public string LastName  {get{ return lastName; } private set{ return lastName;  } }

  public Person(string firstName, string lastName)
  {
      this.firstName = firstName;
      this.lastName = lastName;
  }
}

数か月後、自動プロパティが導入され、再び簡単になりました。

public class Person
{
  public string FirstName {get; set;}
  public string LastName  {get; set;}
}

そして汎用性はそのままです：

public class Person
{
  public string FirstName {get; private set;}
  public string LastName  {get; private set;}

  public Person(string firstName, string lastName)
  {
      FirstName = firstName;
      LastName = lastName;
  }
}

そして、プライベート セッターなしでクラスに行くと、さらに別の利点があります。

var myInstance = new Person{FirstName = "Che", LastName="Guara"}

これまでのところ - 優れています。

しかし今、MVVM が本当に使用したい別の進化があります.. (モデルで!)

public class Person : INotifyPropertyChanged
{
  public event PropertyChangedEventHandler PropertyChanged;

  private string firstName;
  private string lastName;

  public string FirstName
  {
    get{ return firstName; }
    set
    { 
       firstName = value;
       if(PropertyChanged!=null)
        PropertyChanged(this,new PropertyChangedEventArgs("FirstName");
    } 
  }

  public string LastName
  {
    get{ return lastName; }
    set
    { 
       lastName = value;
       if(PropertyChanged!=null)
        PropertyChanged(this,new PropertyChangedEventArgs("LastName");
    } 
  }
}

だから..わかりました..以前ほど短くはありませんが、許容範囲です。

しかし、モデルの進化が何かであるならば、当然のことです..

そして、「Don't Repeat Yourself」が良い原則であることに同意します。

多くの場合、特定の View-Model クラスは必要ありませんが、すべての場合ではありません。

そして、それは大丈夫です。

オブジェクト中心のパラダイムに対する態度全体を変えることがなぜ間違っているのでしょうか?

例:

publie interface IPersistable
{ 
   Guid Id {get;set;}
   DataAccessLayer Dal {get;set}
   void Persist();
   void Populate();
}

public class Person : INotifyPropertyChanged, IPersistable
{
  public DataAccessLayer Dal;

  private Guid Id;

  public Guid Id
  {
     get {return id;}
     set
     {
    id=value; 
    if(PropertyChanged!=null)
        PropertyChanged(this,new PropertyChangedEventArgs("Id");
     }
  }

  public event PropertyChangedEventHandler PropertyChanged;

  private string firstName;
  private string lastName;

  public string FirstName
  {
    get{ return firstName; }
    set
    { 
       firstName = value;
       if(PropertyChanged!=null)
        PropertyChanged(this,new PropertyChangedEventArgs("FirstName");
    } 
  }

  public string LastName
  {
    get{ return lastName; }
    set
    { 
       lastName = value;
       if(PropertyChanged!=null)
        PropertyChanged(this,new PropertyChangedEventArgs("LastName");
    } 
  }

  public void Persist() //assume this is part of IPersistable.
  {
    Dal.Persist(this);
  }

  public void Populate() //assume this is part of IPersistable.
  {
    var t=Populate(Id);
    FirstName = t.Firstname;
    LastName = t.LastName;
  }

}

したがって、モジュールのどこかで、私ができることは次のとおりです。

myObj.Persist();

これは間違った考えですか、それとも良い考えですか? 良いアーキテクチャまたは悪いアーキテクチャ?

その中にはまだ懸念事項の分離があります - 書き方が違うだけです。

本当に頭を悩ませていますが、これに関するあなたの意見に感謝します。

ありがとう。

GY

4

1 に答える 1

2

に関してINotifyPropertyChanged: MVVM は ViewModel で使用するように求めます。これは、WPF が View とDataContextMVVM の ViewModel の間のデータバインディングにこのインターフェイスを利用するためです。それとは別に、INPCプロパティの変更を通知するためのインターフェイスのみであり、好きな場所で使用できます。人々は通常、モデルに実装することは想定されていないと考えていますが、これは間違っていますが、実装する必要もありません。INPCおそらくほとんどの場合、ViewModel でこれらの変更を処理するために、モデルをどこかで使用したい場合にのみ、モデルに実装する必要があります。たとえば、ViewModel による操作によってのみモデルが変更される場合は、実装する必要はありませんINPC。

つまり、モデルは、MVVM パターンで使用されているという事実にとらわれません。

したがって、モデルを設計するときは、システム全体についてあまり考えないでください。変更通知を提供します: 結構です。永続化機能を提供します: 結構です。これは完全に優れた OOP クラスです。モデルが MVVM の適切なモデルになるには、これで十分です。

編集：

問題はMVVM固有のimoではありません。エンティティ (この場合は人) の表現、プロパティの変更の通知 (繰り返しますが、INPC は MVVM 固有ではありません)、および永続性の維持は、1 つのクラスにとって懸念事項が多すぎるかどうかを尋ねるのは理にかなっています。通知と永続化は一種のサービス機能であり、Dal で実際のロジックを分離します。アプリケーションでエンティティを個別に保存およびロードすることが理にかなっているのであれば、なぜ気にしないのでしょうか? なぜそうすべきでないのか、あなたの実際の懸念は何ですか？もちろん、2 つのプロパティを持つクラスの方が優れていますが、それは常にトレードオフです...

要するに、データを保持し、このデータの永続性を維持し、変更を通知することは、クラスに入れるのに適したジョブのバンドルのように聞こえると思います。

これであなたの質問に満足のいく答えが得られるかどうか教えてください。

于 2013-04-10T07:35:15.243 に答える