实体从数据库直接链接到viewModel - 不好的做法？

问题描述：

我与MVVM一起使用实体框架。我的层是这样的：实体从数据库直接链接到viewModel - 不好的做法？

查看
视图模型：提供数据和视图命令。
服务：提供对DAL的访问。包含业务逻辑。
DAL：提供对数据库的访问。我将库模式与UnitOfWork一起使用。

我的ViewModel中的属性或多或少直接绑定到我的数据库中的实体。例如：

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(); 
    } 
}

所以当Save被呼叫时，数据库生成的属性/特性（如ID）被更新/自动生成。

这是否会导致副作用？这是不好的做法吗？

你如何处理它？将数据从数据库传递给视图模型时，是否“分离”或复制对象？或者，传递给视图模型的对象甚至应该是另一种类型？我怎样才能完美地处理这件事？

答

这是否会导致副作用？这是不好的做法吗？

号你是不是违反了MVVM模式的任何原则和你有完全分离的关注，更重要的抽象从DAL技术掉，这是因为接近理想地使用的是具有一种抽象的模型/服务实现层不是每个人都做的（一些开发人员会将DbContext派生的类作为Model对象注入，并直接调用Save()）。

你如何处理？将数据从数据库传递给视图模型时，是否“分离”或复制对象？或者，传递给视图模型的对象甚至应该是另一种类型？我怎样才能完美地处理这件事？

你可以通过让你依赖于抽象，而不是结核由要么通过IMyEntity物体周围或确保MyEntity走得更远是一个基类和更专业的EF DAL类的DAL层周围的处理和传递，但我以前发现这对于这些类型的应用程序来说是过度的。

由于代码膨胀，我不喜欢使用复制对象。我已经非常有效地使用了子/基类实体的层次结构，但是，除非您知道一个事实，即您需要从一开始就应对多个子类型，否则这是更多的工作，并且没有真正的理由这么做。

实体从数据库直接链接到viewModel - 不好的做法？

相关推荐