存储库模式和数据类型返回

Question

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

Answer 1

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

无论如何，依靠一些服务来完成解析都是您的基础设施的一部分。在大多数Repository实现中，在返回之前必须对持久化数据进行一些操作，所以这是一件好事。

例如，如果您的存储库正在返回一个域层对象，但您的持久性使用L2S，则可能需要将L2S数据映射到域对象。你需要依赖仓库以外的东西来做到这一点。把它称为服务或其他什么，你可能不想用存储库代码来映射。

Answer 2

解析方法可能是您的资源库类中的私有方法，因此隐藏了公共实际回购方法的实际解析。或者，它可能是生活在Util类中的扩展方法。

我认为你在考虑不把该字符串解析到svc层时是正确的，因为它似乎违反了SRP。

Answer 3

存储库应该肯定会返回业务对象。

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

你在声明你不应该让你的Repository类伸出你的服务层是正确的，所以无论你用什么重构方法清理存储库，它都应该在该层完成，而不是更高。

Answer 4

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

我想到的方式是：谁最关心数据的实际存储？如果字符串格式是某个遗留系统的工件，而不是业务逻辑的重要组成部分（即，如果要更改存储机制，则会删除该字符串），然后将其隐藏在存储库后面。如果它是数据的重要组成部分，但是您将其从业务逻辑中抽象出来，请将其放入服务中。

如果您确实将其保留在存储库中，则可以创建一个特殊的类来处理该字符串并将其作为接口传递给存储库。这样你可以像疯了一样单元测试字符串处理代码（如果需要的话，可以在其他地方重新使用它）并简化存储库。