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

【问题标题】：Entity from database directly linked to viewModel - bad practice?数据库中的实体直接链接到 viewModel - 不好的做法？
【发布时间】：2016-11-04 17:18:37
【问题描述】：

我将实体框架与 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）会自动更新/生成。

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

你是怎么处理的？将对象从数据库传递到视图模型时，您是否“分离”或复制对象？或者传递给视图模型的对象是否应该是另一种类型？我该如何完美处理？

【问题讨论】：

标签： c# wpf entity-framework mvvm

【解决方案1】：

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

没有。您没有违反 MVVM 模式的任何原则，这尽可能接近理想，因为您完全分离了关注点，更重要的是从您正在使用的 DAL 技术中抽象出来，并使用并非每个人都这样做的抽象模型/服务实现层（一些开发者会将DbContext派生类作为模型对象注入并直接调用Save()）。

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

您可以通过传递IMyEntity 对象或确保MyEntity 是一个基类并处理并传递一个更专业的EF DAL 类来确保您依赖于抽象而不是具体化，从而走得更远。层，但我之前发现这对于这些类型的应用程序来说太过分了。

由于代码膨胀，我不喜欢使用复制对象。我之前非常有效地使用了子/基类实体层次结构，但是，它需要更多的工作并且没有真正的理由这样做，除非您知道从一开始就需要满足多种子类型的需求。

【讨论】：