使用 IDal<T> 接口包装 EntityFrameWork答案

【问题标题】：Wrapping EntityFrameWork with IDal<T> interface使用 IDal<T> 接口包装 EntityFrameWork
【发布时间】：2012-10-15 10:24:12
【问题描述】：

我想用IDal<T> 接口仅用CRUD operations 包装我的EntityFrameWork 类。

我想为每个实体创建对应的 BL 数据模型

意思是如果我有TempEntity 我将创建TempBlObj 和接口IDal<TempBlObj>

是否有完成此类任务的指导方针？

我在实现 Save(TempBlObj) 时遇到问题

实体中的保存是由：

mDbEntities.SaveChanges();

这取决于对实体引用所做的更改。

有什么解决办法吗？

更新

我这样做是为了模拟我的IDal<T> 界面

例如为了改变 TempEntity.status

我必须创建一个具体的方法 ChangeStatus() 而不是通用的 CRUD ：Save(BlObj item)

与实体保存类似

..take reference to some entity, do some change.. 和

mMamDbEntities.SaveChanges();

我尝试添加 BlObjects 以放松 Bl 和具体 EntityFW 之间的依赖关系

更一般：

在使用 ORM 时，使用IDal<T> intreface（CRUD 操作）进行松散封装的最佳做法是什么？

【问题讨论】：

我认为您将与框架作斗争！我认为您必须专门分离所有其他实体才能实现这一目标。你真的需要它以这种方式工作吗？
用于单元测试。否则你会怎么做？
我无法准确地可视化您正在尝试做什么，更多上下文可能会有所帮助。
虽然我可以看到隔离代码以进行单元测试的优点，但考虑到 DAL（即 EntityFramework）是一个众所周知的数量，仅仅拥有它不是更实用吗？针对真实 DAL 运行的单元测试，并在您的测试设置中创建测试数据库实例等？
你会如何模拟 EntityFW ？

标签： c# .net entity-framework architecture

【解决方案1】：

拯救实体的责任不应该是实体本身的工作。这是个坏主意。你可以考虑在你的情况下实现repository pattern。

【讨论】：

用于单元测试。否则你会怎么做？
我在实现 Save(TempBlObj) 时遇到问题，因为保存在实体中是由：mDbEntities.SaveChanges();这取决于对实体引用所做的更改。
“拯救一个实体的责任不应该是实体本身的工作。” - 它可以。这种模式是“ActiveRecord”或“Row Gateway”

【解决方案2】：

在为我的系统规划存储库时，我会尽量记住几个事实：

O/RM 可以帮助我实现存储不感知的实体。这意味着我不区分业务实体和数据库实体。我有一个User 实体——不管怎样，ORM 都应该持久化它，我不会在这里介绍额外的层。
我会从限制较少的界面开始：

     
    interface IDal {
        T Get<T>(id);
        void Save(object o); //or T, if needed
        IQueryable<T> Query<T>();
    }

而且 - 可以很好地模拟它（使用 Moq 的示例）。

     
    var users = new List<User>(){ /* Users here */}
    var mockedRepository = new Mock<IRepository>();

    //getup GET
    mockedRepository.Setup(
        self => self.Get<User>( It.IsAny<int>() )
    .Returns( (int id) => _users.First(u => u.Id == id) );

【讨论】：

但对于 EF，T 是一个具体的 DBEntity 项。没有？
那么 context.SaveChanges() 将如何工作？它依赖于 EF DTO 上的更改检测，不是吗？