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

Question

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

Answer 1

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

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

你断言你不应该让你的Repository类接触到你的服务层是正确的，所以无论你采取哪种重构方法来清理存储库，它都应该在那一层完成，而不是更高层。

Answer 2

由于存储库应该作为内存对象的集合，它应该返回应用程序期望处理的任何类型对象的实例。如果您的应用程序需要解析对象，则应该返回该对象。

依靠某些服务进行解析无论如何都是您的基础架构的一部分。在大多数Repository实现中，您必须在返回之前对持久化数据执行某些操作，因此这是一件好事。

例如，如果您的存储库正在返回域层对象，但您的持久性使用的是L2S，则可能需要将L2S数据映射到域对象。您需要依赖存储库之外的东西来执行此操作。将其称为服务或其他任何东西，您可能不希望使用映射来存储存储库代码。

Answer 3

解析方法可能是存储库类中的私有方法，因此隐藏了来自公共实际存储库方法的实际解析。或者，它可以是生活在Util类中的扩展方法。

我认为你没有将该字符串的解析放在svc层中是正确的，因为它似乎违反了SRP。

Answer 4

我首选的选择是不要将数据存储在固定宽度的分隔字符串中。 ：）

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

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