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

时间:2018-05-17 09:27:45

标签: c# wpf entity-framework

我已经使用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);
    }
}

2 个答案:

答案 0 :(得分:2)

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

为何专注于EF?所有人的架构都是一样的....简单地说:实体; DataAccessLayer;商业服务; GUI(视图,视图模型,服务 - 仅使用实体和服务)

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

  1. Assembly.Entities
  2. Assembly.BusinessServices
  3. Assembly.DAL
  4. Assembly.GUI
  5. 祝你好运

答案 1 :(得分:1)

一些提示:

  • 使用IoC容器管理所有/大多数依赖项,包括DbContext。这样你就可以更好地测试一切。然后,您可以配置这些依赖项的范围(单例,瞬态等)。一些流行的选项是autofac,castle windsor,ninject或来自.net的内置ioc容器。

  • 查看存储库模式,它将极大地解耦所有内容

  • 让您的ViewModel尽可能保持愚蠢

  • 将来自您的EF模型的数据映射到DTO,不要直接在您的视图中使用这些实体

  • 查看SOLID原则