design-patterns - 存储库设计模式

标签 design-patterns repository-pattern

我见过很多存储库模式的实现。具体2种

  • 它们公开了可查询的通用存储库,并期望来自服务类的 Lamba 表达式以从数据库中获取数据。
  • 根据业务需求编写方法从数据库中获取数据,并封装检索数据的逻辑(甚至是 lambda)。

  • 哪个是更好的方法?

    最佳答案

    我真的更喜欢第二个。

    即使我在 .NET 世界上看过顶级博主的文章,对我来说,可查询的内容在存储库中都是邪恶的。

    原因:

  • 存储库就像对象的集合,但存储在其实现定义的任何位置。
  • 存储库抽象了数据映射到对象的方式。数据存储可以是任何东西,但业务依赖存储库来检索、添加、更新或删除域对象。
  • 对底层存储的任何读取或写入访问都必须由存储库本身或任何其他底层管理。

  • Queryable 破坏了这些要点和/或原因中的大部分。

    例如,如果可以在 IQueryable 上使用 LINQ,为什么要设计 GetProductByName、GetProductByCode?

    并且 Queryable 在 n 层场景中效果不佳,因为除了返回延迟集的层之外,您将无法访问另一层中的数据库连接。

    我不认为“可查询”概念和存储库对任何软件设计都有好处,因为它告诉存储库是无用的。

    Queryable 就像设计一个 GetAll 方法。存储库中的 GetAll 有什么意义?存储库将检索所有域对象,您将在业务中过滤它们。但是......等等......存储库不应该检索具有某些标准的域对象,是吗?

    尽管我发现可查询与存储库不兼容,但对我来说,设计和实现一些接受 lambda 表达式或任何委托(delegate)以提供某种过滤器或行为的存储库方法是可以的。这不是延迟执行,而是委托(delegate)。

    关于design-patterns - 存储库设计模式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5166888/

    相关文章:

    c# - 没有为类型 'System.Int64' 定义实例属性

    entity-framework - 使用 Repository/UoW/DI 抽象 EntityFramework.dll 引用

    c# - 如何从存储库中检索域对象

    c# - 使用 Dependency Resolver 是一种不好的做法吗?

    c# - 派生静态成员

    design-patterns - 过度关注测试总体上是一件坏事吗?

    java - 创建对象时变量值发生变化如何读取?

    C#、CaSTLe Windsor 和复合设计模式

    repository-pattern - 这是使用 petapoco 的工作单元和存储库模式(带有事务)的糟糕或错误设计/实现吗

    unit-testing - 测试真实存储库