viewModelに直接リンクされたデータベースのエンティティ - 悪い習慣ですか？

Question

私はMVVMと共にEntity Frameworkを使用しています。 私の層は、次のようになります。

• ビュー
• のViewModel：データを提供して表示するためのコマンド。
• サービス：DALへのアクセスを提供します。ビジネスロジックを含みます。
• DAL：データベースへのアクセスを提供します。私はUnitOfWorkと共にリポジトリパターンを使用しています。

私のViewModelsのプロパティは、データベースからのエンティティにある程度直接バインドされています。例：Saveが呼び出されたときに

public class MyViewModel 
{ 
    private MyEntity _myEntity; 

    private MyService _myService; 

    // A property which is bound to my view (bidirectionally) 
    public string TextToDisplay 
    { 
     get { return _myEntity.SomeText; } 
     set 
     { 
      if (_myEntity.SomeText != value) 
      { 
       _myEntity.SomeText = value; 
       RaisePropertyChanged("TextToDisplay"); 
      } 
     } 
    } 

    // Method called by a command when the "Save"-button is pressed 
    private void Save() 
    { 
     _myService.Save(_myEntity); 
    } 
} 

public class MyService 
{ 
    private MyRepository _myRepository; 
    private IUnitOfWork _unitOfWork; 

    public void Save(MyEntity myEntity) 
    { 
     _myRepository.Insert(myEntity); 
     _unitOfWork.Save(); 
    } 
} 

だから、（IDのような）データベースが生成した属性/プロパティが自動的に生成/更新されます。

これは副作用を引き起こしますか？それは悪い習慣ですか？

どのように処理しますか？データベースからビューモデルにオブジェクトを渡すときに、オブジェクトを「切り離す」か、コピーしますか？または、オブジェクトが別の型であってもviewmodelに渡される必要がありますか？これをどうすれば完全に処理できますか？

Answer 1

これは副作用を引き起こしますか？それは悪い習慣ですか？

いいえMVVMパターンの原則に違反していません。これは、懸念事項を完全に分離し、より重要なことに抽象モデル/全員ではないサービス実装層（一部の開発者はDbContext由来のクラスをModelオブジェクトとして注入し、Save()を直接呼び出します）。

どのように処理しますか？データベースからビューモデルにオブジェクトを渡すときに、オブジェクトを「切り離す」か、コピーしますか？または、オブジェクトが別の型であってもviewmodelに渡される必要がありますか？これをどうすれば完全に処理できますか？あなたはどちらかの周りIMyEntityオブジェクトを渡すか、確認してくださいMyEntityは、基本クラスで、より専門的なEFのDALのクラスは、DAL層を中心に取り扱われ、渡されたことをすることによって、あなたが代わりに結石の抽象化に依存することによって、さらに行くことができる

しかし、私は以前に、これがこれらのタイプのアプリケーションのために過度のものであることを発見しました。

私は、コードの膨張のためにコピーオブジェクトを使用したくないです。私は子供/基本クラスのエンティティ階層を非常に効果的に使用しましたが、最初から複数の子タイプを処理する必要があるという事実を知らない限り、それはより多くの作業であり、そうするべき本当の理由はありません。