Question

我将实体框架与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）。

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

你是如何处理的？你＆＃34;分离＆＃34;或者将对象从数据库传递到viewmodel时复制对象？或者对象传递给viewmodel甚至是另一种类型？我怎么能完美地处理这个？

Answer 1

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

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

你是如何处理的？将数据库从数据库传递到viewmodel时，是否“分离”或复制对象？或者对象传递给viewmodel甚至是另一种类型？我怎么能完美地处理这个？

您可以通过传递IMyEntity对象或确保MyEntity是基类并且处理更专业的EF DAL类来确保依赖于抽象而不是具体结果。在DAL层周围传递，但我之前发现这对于这些类型的应用程序来说是过度杀伤。

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

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

1 个答案: