1

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

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

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

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

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

因为实体中的保存是通过以下方式完成的:

mDbEntities.SaveChanges();

这取决于对实体参考所做的更改。

有什么解决办法吗?

更新

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

例如为了改变 TempEntity.status

我将不得不创建一个具体的方法ChangeStatus()而不是通用的CRUDSave(BlObj item)

因为保存实体就像

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

mMamDbEntities.SaveChanges();

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

更一般:

使用 ORM 时,使用IDal<T>接口(CRUD操作)进行松散封装的最佳实践是什么?

4

2 回答 2

0

在为我的系统规划存储库时,我会尝试记住几个事实:

  • 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) );

于 2012-10-26T09:01:55.860 回答
0

拯救实体的责任不应该是实体本身的工作。这是个坏主意。您可以考虑在您的情况下实施存储库模式

于 2012-10-25T09:09:20.227 回答