存储库没有接口,没有抽象=异常?

时间:2011-07-26 15:30:39

标签: c# asp.net unit-testing entity-framework repository

我需要有关设计这样一个存储库的反馈,它会帮助我在晚上休息,认真...... 我无意为Web表单编写测试,涉及的开销太大 我无意明天,下个月或明年更改ORM或数据库 我需要一个地方来集中查询逻辑并避免代码重复。对吗?...

public class StuffRepository // no contract, I simply instanciate StuffRepository
{
    // Scope is Per-Request, DI, no abstraction...
    protected StuffDb DbContext = ObjectFactory.GetInstance<StuffDb>();

    // Returns a Stuff, an Entity (EF), no abstraction
    public Stuff Get(Guid id)
    {
        return DbContext.Stuff.FirstOrDefault(s => s.Id == id);
    }
}

我使用完全抽象的存储库,在Web表单上的MVP架构,用于单个页面可测试性和抽象实体(DTO和域/模型对象)。它永远不会结束,它永远不够,永远不会完美。

我是否违反了所有的规则和原则并且产生了一种异常,称这是一个存储库?

如果我只是将其重命名为StuffDAL,它会突然有意义吗?

由于

2 个答案:

答案 0 :(得分:3)

老实说我对存储库有同样的感觉,最后在上个月阅读了大量文章后,我的印象是我一直都在做存储库。我认为是一个存储库实际上只是一个DAO或DAL,这是一个抽象,使它更容易说,“持久性,给我回复我的对象”,或者“坚持,持有这个对象直到我以后想要它”。

你知道吗,我真的不关心它叫什么,如果它正确抽象出我需要的东西,很容易测试,完成工作,很容易改变。

那么,它是一个由Eric Evans设想的存储库,它有一个内存存储对象吗?不,不是真的,但是,嘿,我不会拒绝你的。

答案 1 :(得分:2)

对我而言,存储库可以为您提供数据的全局持久性,包括缓存不会再次获取数据库。除了CRUD之外,它还具有专用功能。 然而,DAL允许您访问数据库,该数据库是唯一负责通过应用程序的不同调用来保持数据存在的数据库,并且通常仅限于对数据库的CRUD调用

从你写的内容来看,你绝对是第二选择。随着其他一些事情的增加,我可能不会那么严格。

但看看here,你会发现两者之间的差异都是相对的。

AS不会使用界面,我不推荐它。一段时间后添加几行非常有用......