没有接口和抽象的存储库=偏差

本文关键字：偏差 存储 抽象的 接口 | 更新日期: 2023-09-27 18:03:27

我需要设计这样一个存储库的反馈，它会帮助我晚上休息，真的…
我无意为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);
    }
}

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

我是否违反了所有的规则和原则，并产生了一个异常，称其为存储库?

如果我把它重命名为StuffDAL，它会突然有意义吗?

谢谢

没有接口和抽象的存储库=偏差

老实说，我对仓库也有同样的感觉，最后在上个月阅读了大量关于它的文章后，我真的觉得我一直以来对仓库的处理都是错误的。我所认为的存储库实际上只是一个DAO或DAL，是一种抽象，可以更容易地说:"持久性，把我的对象还给我"，或者"持久性，保留这个对象，直到我以后想要它"。

你知道吗，我真的不在乎它叫什么，只要它能正确地抽象出我需要的东西，易于测试，完成工作，易于更改。

那么，它是Eric Evans设想的具有内存中对象存储的存储库吗?不，不完全是，但是，嘿，我不会告发你的。

对我来说，存储库在这里为您提供数据的全局持久性，包括缓存，例如不再次获取您的数据库。它也是专用于功能的东西，而不是CRUD。然而，DAL允许您访问数据库，它是唯一负责在来自应用程序的不同调用中使数据持久的人，并且通常仅限于对数据库的CRUD调用

从你写的来看，你肯定是第二选择。如果再加上一些其他的东西，我可能就不会这么严格了。

但是看一下这里，你会发现两者之间的区别都是相对的

关于不使用接口的意愿，我不建议使用它。添加几行很有用，过了一会儿…

相关文章：