Question

我已经使用WPF MVVM和Entity Framework编写了一个应用程序几个月了，我意识到我的代码架构开始变得混乱。我似乎无法找到一种方法将EF和WPF正确连接在一起，同时保持两层不同且连贯的数据。

实体总是分离的，因为保持它们的连接意味着我们必须为整个应用程序保留单个DbContext实例，这是不推荐的。

目前，这是我的架构：

大多数写操作都放在永不服务的服务中实体作为参数，只有它们的ID。
ViewModels调用服务，但由于未附加实体，因此视图未更新
ViewModels直接从DbContext检索数据，根据需要显示的内容选择要包含的属性

问题：

感觉不对。我觉得我没有正确使用EF，它让我想起了。
我最终得到了许多具有未定义属性的实体实例（我不能总是包含所有这些实例，它会消耗太多内存）
我的ViewModels中有EF代码

除了非常基本的教程之外，我似乎无法在线找到任何适当的WPF - EF架构示例。

示例：

class ViewModel : BaseViewModel
{
    private Service _service;

    public ViewModel(Service service)
    {
        LoadEntities();
    }

    public IList<Entity> Entities { get; set; }

    private void LoadEntities()
    {
        using(var context = new DbContext())
        {
            Entities = context.Entities
                .Include("Reference.Foo")
                .ToList();
        }
    }

    private void DeleteEntity(Entity entity)
    {
        _service.DeleteEntity(entity.Id);
        Entities.Remove(entity);
    }
}

Answer 1

这是一个非常“大”的问题......并且在一个简单的帖子上很难回答

为何专注于EF？所有人的架构都是一样的....简单地说：实体; DataAccessLayer;商业服务; GUI（视图，视图模型，服务 - 仅使用实体和服务）

你说“目前，这是我的架构”==＆gt;对我来说，3分是错误的。给实体服务不是问题，将实体附加到viewmodel并且不要直接在viewmodel中调用DB / EF而是使用服务

Assembly.Entities
Assembly.BusinessServices
Assembly.DAL
Assembly.GUI

Answer 2

一些提示：

使用IoC容器管理所有/大多数依赖项，包括DbContext。这样你就可以更好地测试一切。然后，您可以配置这些依赖项的范围（单例，瞬态等）。一些流行的选项是autofac，castle windsor，ninject或来自.net的内置ioc容器。
查看存储库模式，它将极大地解耦所有内容
让您的ViewModel尽可能保持愚蠢
将来自您的EF模型的数据映射到DTO，不要直接在您的视图中使用这些实体
查看SOLID原则

与WPF和实体框架一起使用 - 什么架构？

2 个答案: