【问题标题】:Repository pattern and data type returned返回的存储库模式和数据类型
【发布时间】:2009-06-05 18:25:32
【问题描述】:

我正在使用存储库模式并且想知道我应该返回什么数据类型。在我的数据库中,我有一个可变长度的字符串,需要根据固定长度进行分解。我最初考虑传递字符串并让服务层根据配置的列的长度进行解析。我不太喜欢将字符串从存储库层传递出去的想法,我宁愿传递一个完整的对象。传递字符串似乎没有足够的责任分离,但是让存储库不得不使用另一种方法来获取应该如何解析字符串并进行解析似乎对于 repo 来说工作量太大。在这种情况下,repo 和服务的责任应该是什么?

【问题讨论】:

    标签: c# .net repository-pattern ddd-repositories


    【解决方案1】:

    存储库绝对应该返回业务对象。

    至于谁应该做解析,你可以做很多事情。也许您可以使用辅助函数或类似的东西将字符串解析为正确的格式。如果它在 repo 之外没有用,您可以重构代码以使其更具可读性。

    您断言您不应该让您的 Repository 类接触到您的服务层是正确的,因此无论您采取何种重构方法来清理存储库,都应该在该层完成,而不是更高。

    【讨论】:

    • 是的,我并没有考虑让 repo 与服务层对话,而是让服务进行解析,但要让 repo 进行解析(或通过传入的接口)并返回模型对象。谢谢+1
    【解决方案2】:

    由于存储库应该充当内存对象的集合,它应该返回您的应用程序期望处理的任何类型的对象的实例。如果您的应用程序需要一个已解析的对象,您应该返回它。

    无论如何,依赖某些服务进行解析都是您的基础架构的一部分。在大多数 Repository 实现中,您必须在返回持久化数据之前对其进行处理,所以这是一件好事。

    例如,如果您的存储库返回一个域层对象,但您的持久性使用 L2S,您可能希望将 L2S 数据映射到域对象。您需要依赖存储库之外的东西来执行此操作。将其称为服务或其他名称,您可能不想将存储库代码与映射混为一谈。

    【讨论】:

    • 那么即使repository要调用另一个对象来获取数据,如何解析数据呢?我有点倾向于这种方式......所以如果以后数据存储发生变化,我只需要处理 repo 而不是服务。
    • 在您的情况下,它可能与扩展方法或其他东西一样简单,正如 Joseph 所指出的那样。但是,是的,让存储库只处理持久性问题,而将解析规则留给其他对象可能是最好的。
    【解决方案3】:

    解析方法可以是存储库类中的私有方法,从而对公共实际 repos 方法隐藏实际解析。或者,它可以是一个存在于 Util 类中的扩展方法。

    我认为您认为不将该字符串的解析放在 svc 层的想法是正确的,因为它似乎违反了 SRP。

    【讨论】:

      【解决方案4】:

      我的首选不会首先将数据存储在固定宽度分隔的字符串中。 :)

      我的想法是这样的:谁最关心数据的实际存储?如果字符串格式是某些遗留系统的产物,而不是业务逻辑的重要部分(即,如果您要更改存储机制,您将摆脱字符串),则将其隐藏在存储库后面。如果它是数据的重要部分,但您是从业务逻辑中抽象出来的,请将其放入服务中。

      如果您确实将其保留在存储库中,您可以创建一个特殊的类来操作该字符串并将其(作为接口)传递给存储库。这样您就可以疯狂地对字符串处理代码进行单元测试(并在需要时在其他地方重用它)并使您的存储库保持简单。

      【讨论】:

        猜你喜欢
        • 2018-05-27
        • 1970-01-01
        • 2015-04-16
        • 2015-10-06
        • 1970-01-01
        • 1970-01-01
        • 2019-02-19
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多