返回的存储库模式和数据类型
我正在使用存储库模式，并且想知道应该返回什么数据类型。 在我的数据库中，我有一个可变长度的字符串，需要根据固定长度进行分解。 我最初考虑传递字符串并让服务层根据配置的列的长度进行解析。 我真的不喜欢从存储库层传递字符串的想法，宁愿传递一个完整的对象。 传递字符串似乎没有足够的责任分离，但是让存储库必须转到另一个方法来获取如何解析字符串并进行解析对于存储库来说似乎是太多的工作。 在这种情况下，回购和服务的责任应该是什么？有什么建议吗？
I am using the repository pattern and was wondering about what data type I should return. In my database I have a string that is variable length that needs to be broken up based off of fixed lengths. I was initially thinking of passing out the string and letting the service layer do the parsing based on the lengths of the configured columns. I dont really like the idea of passing a string out of the repository layer, would rather pass out a complete object. Passing out the string seems like not enough separation of responsibility, but having the repository having to go to another method to get how the string should be parsed and doing the parsing seems like too much work for the repo. Any suggestions of what should be the responsibility of the repo and service in this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
存储库绝对应该返回业务对象。
至于谁应该进行解析，您可以做很多事情。 也许您可以使用辅助函数或类似的函数将字符串解析为正确的格式。 如果它在存储库之外没有用，您可以重构代码以使其更具可读性。
您断言不应该让 Repository 类触及服务层是正确的，因此无论您采取何种重构方法来清理存储库，都应该在该层完成，而不是更高层。
The Repository should definitely return the Business Object.
As for who should do the parsing, you could do a number of things. Maybe you could use a helper function or something similar to parse the string into the correct format. If it's not going to be useful outside of the repo, you could just refactor the code to make it more readable.
You are correct in asserting that you shouldn't have your Repository class reach out to your service layer, so whatever method of refactoring you take to clean up the repository it should be done at that layer, not any higher.
由于存储库应该充当内存对象的集合，因此它应该返回应用程序期望处理的任何类型的对象的实例。 如果您的应用程序需要一个已解析的对象，您应该返回该对象。
无论如何，依赖某些服务来进行解析都是基础设施的一部分。 在大多数存储库实现中，您必须在返回持久数据之前对其进行一些操作，因此这是一件好事。
例如，如果您的存储库返回域层对象，但您的持久性使用 L2S，您可能希望将 L2S 数据映射到域对象。 您需要依赖存储库之外的东西来执行此操作。 将其称为服务或其他什么，您可能不想将存储库代码与映射混在一起。
Since the Repository is supposed to act as a collection of in memory objects, it should return an instance of whatever type of object your application is expecting to deal with. If your application expects a parsed object, you should return that.
Relying on some service to do the parsing is all a part of your infrastructure anyway. In most Repository implementations you have to do something with your persisted data before you return it, so this is a good thing.
For example, if your Repository is returning a Domain layer object, but your persistence is using L2S, you might want to map the L2S data to the domain object. You would need to rely on something outside the repository to do this. Call it a service or whatever, you probably don't want to kluge the repository code with the mapping.
解析方法可以是存储库类中的私有方法，从而隐藏公共实际存储库方法中的实际解析。 或者，它可以是位于 Util 类中的扩展方法。
我认为您关于不将该字符串的解析放在 svc 层的想法是正确的，因为它似乎违反了 SRP。
The parsing method could be a private method within your repository class, thus hiding the actual parsing from the public actual repos method. Alternatively, it could be an extension method living in a Util class.
I think you're correct in your thinking about not putting the parsing of that string in the svc layer, since it would seem to violate the SRP.
我的首选不会首先将数据存储在固定宽度的分隔字符串中。 :)
我的想法是这样的：谁最关心数据的实际存储？ 如果字符串格式是某些遗留系统的产物，而不是业务逻辑的重要部分（即，如果您要更改存储机制，则需要删除该字符串），然后将其隐藏在存储库后面。 如果它是数据的重要组成部分，但您将其从业务逻辑中抽象出来，则将其放入服务中。
如果您确实将其保留在存储库中，则可以创建一个特殊的类来操作该字符串并将其（作为接口）传递到存储库。 这样你就可以像疯狂一样对字符串处理代码进行单元测试（如果需要的话可以在其他地方重用它）并使你的存储库保持简单。
My preferred choice would not to store the the data in a fixed-width delimited string in the first place. :)
The way I think about it is this: Who cares the most about the actual storage of the data? If the string format is an artifact of some legacy system and not an essential part of business logic (i.e. if you were to change storage mechanisms you'd get rid of the string) then hide it behind the repository. If it's an essential part of the data but you are abstracting it from the business logic, put it in the service.
If you do leave it in the repository, you can create a special class for manipulating that string and pass it in (as an interface) to the repository. That way you can unit test the string-handling code like crazy (and reuse it else where if needed) and leave your repository simple.