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

本文关键字：实体 viewModel 数据库 链接 | 更新日期: 2023-09-27 18:16:17

我使用实体框架与MVVM在一起。我的图层看起来像这样:

    <
  • 视图/gh>
  • ViewModel:为视图提供数据和命令。
  • Service:提供对DAL的访问。包含业务逻辑。
    • DAL:提供对数据库的访问。我将仓库模式与UnitOfWork一起使用。

我的ViewModels中的属性或多或少直接绑定到我的数据库中的实体。例子:

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)会自动更新/生成。

这会导致副作用吗?这种做法不好吗?

你是怎么处理的?当将对象从数据库传递到视图模型时，您是否"分离"或复制对象?或者传递给视图模型的对象应该是另一种类型吗?我怎样才能完美地处理这件事?

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

这会导致副作用吗?这种做法不好吗?

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

你是怎么处理的?当将对象从数据库传递到视图模型时，您是否"分离"或复制对象?或者传递给视图模型的对象应该是另一种类型吗?我怎样才能完美地处理这件事?

你可以更进一步，通过传递IMyEntity对象来确保你依赖抽象而不是具体，或者确保MyEntity是一个基类，并且一个更专门的EF DAL类被处理并在DAL层周围传递，但我以前发现这对这些类型的应用程序来说是多余的。

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

相关文章：