我正在使用存储库模式并且想知道我应该返回什么数据类型。在我的数据库中，我有一个可变长度的字符串，需要根据固定长度进行分解。我最初考虑传递字符串并让服务层根据配置列的长度进行解析。我真的不喜欢从存储库层传递字符串的想法，宁愿传递一个完整的对象。传递字符串似乎没有足够的责任分离，但是让存储库不得不使用另一种方法来获取应该如何解析字符串并且进行解析似乎对于 repo 来说工作量太大。在这种情况下，回购和服务的责任应该是什么？
问问题
1542 次
4 回答
3
存储库绝对应该返回业务对象。
至于谁应该做解析，你可以做很多事情。也许您可以使用辅助函数或类似的东西将字符串解析为正确的格式。如果它在 repo 之外没有用，您可以重构代码以使其更具可读性。
您断言您不应该让您的 Repository 类接触到您的服务层是正确的，因此无论您采用何种重构方法来清理存储库，都应该在该层完成，而不是更高。
于 2009-06-05T18:29:31.277 回答
2
由于存储库应该充当内存对象的集合，因此它应该返回您的应用程序期望处理的任何类型的对象的实例。如果您的应用程序需要一个已解析的对象，您应该返回它。
无论如何，依靠某些服务进行解析都是您基础架构的一部分。在大多数 Repository 实现中，您必须在返回持久数据之前对其进行处理，所以这是一件好事。
例如，如果您的 Repository 返回一个域层对象，但您的持久性使用 L2S，您可能希望将 L2S 数据映射到域对象。您需要依赖存储库之外的东西来执行此操作。将其称为服务或其他名称，您可能不想将存储库代码与映射混为一谈。
于 2009-06-05T18:30:58.387 回答
0
解析方法可以是存储库类中的私有方法，从而对公共实际 repos 方法隐藏实际解析。或者，它可以是一个存在于 Util 类中的扩展方法。
我认为您认为不将该字符串的解析放在 svc 层中的想法是正确的，因为它似乎违反了 SRP。
于 2009-06-05T18:29:08.470 回答
0
我的首选不会首先将数据存储在固定宽度的分隔字符串中。:)
我的想法是这样的：谁最关心数据的实际存储？如果字符串格式是某些遗留系统的产物，而不是业务逻辑的重要部分（即，如果您要更改存储机制，您将摆脱字符串），那么将其隐藏在存储库后面。如果它是数据的重要组成部分，但您是从业务逻辑中抽象出来的，请将其放入服务中。
如果您确实将其保留在存储库中，则可以创建一个特殊的类来操作该字符串并将其（作为接口）传递给存储库。这样您就可以疯狂地对字符串处理代码进行单元测试（并在需要时在其他地方重用它）并使您的存储库保持简单。
于 2009-06-05T18:32:00.600 回答