我的存储库是否有太多逻辑？
我有一个旧数据库，我的新应用程序必须与之交互。旧数据库总体上过度规范化且设计不佳。例如，我的域中的一个对象代表数据库中的五个表。我想让我的域层免受遗留数据库中的工件的影响。我应该在这里使用什么模式？
乍一看，我想到了存储库模式。我会将我的对象传递到存储库，并让它处理将数据分成五个表的操作。但是，有人建议必须完成的所有映射都会向存储库添加太多逻辑。那么，存储库在这里是一个糟糕的选择吗？我应该将存储库与其他模式（如适配器）一起使用吗？或者在这种情况下存储库是正确的选择吗？
I have a legacy database that my new application has to interact with. The old database is over-normalized and poorly designed in general. For instance, one object in my domain represents five tables in the database. I want to keep my domain layer free of artifacts from the legacy database. What pattern should I use here?
At first glance, I think about Repository Pattern. I would pass my object to the repository and let it handle splitting the data up into the five tables. However, it was suggested that all the mapping that must be done adds too much logic to the repository. So, it Repository a bad choice here? Should I use Repository with another pattern (like Adapter)? Or is Repository the right choice in this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
存储库模式在这里是合适的，但是按照 DanP 的建议，使用 Data Mapper 将有助于坚持单一责任原则。 NHibernate 和实体框架等 ORM 通常有助于发挥数据映射器的作用，但如果您的数据存储不利于使用 ORM，那么您自己实现此逻辑可能是合适的。
Jeff Morris 提供了一个在存储库模式上下文中使用数据映射器的很好的示例 此处。
但郑重声明，ORM 的工作是弥合对象关系阻抗不匹配。关系数据库模式在结构上通常与域模型不同。您的数据库很可能由于其他原因而设计不佳，但实体和表之间缺乏一对一关系本身不应被理解为设计不佳的指标。从 DDD 的角度来看，数据库被视为应用程序域的持久性存储，数据库可能已针对其编写服务的原始域进行了适当的规范化。
The Repository pattern is appropriate here, but using Data Mapper, as suggested by DanP, will aid in adhering to the Single Responsibility Principle. ORMs such as NHibernate and Entity Framework generally facilitate the role of the Data Mapper, but it can be appropriate to implement this logic yourself if your data store isn't conducive to using an ORM.
Jeff Morris provides a pretty good example of using Data Mapper within the context of the Repository pattern here.
For the record though, the job of an ORM is to bridge the object-relational impedance mismatch. A relational database schema will often differ in structure from the domain model. Your database may very well be poorly designed for other reasons, but the lack of a one to one relationship between entities and tables shouldn't by itself be understood as an indicator of poor design. Viewed from a DDD perspective, where the database is considered the persistence store for an application domain, the database may have been normalized appropriately for the original domain it was written to serve.
我认为 数据映射器 模式就是您所追求的。顺便说一句，您可能可以在这一系列帖子，作者：Davy Brion。
不过我很感兴趣，为什么不考虑像 NHibernate 这样的东西，而不是尝试自己做所有肮脏的工作呢？
I think the Data Mapper pattern is what you're after. Incidentally, you can probably gain quite a few insights about hand-rolling your data access in this series of posts by Davy Brion.
I'm interested though, why not look towards something like NHibernate instead of trying to do all the dirty work yourself?
网关模式可能有帮助吗？创建旧数据库的网关。将所有转换逻辑放在网关中。
Might the Gateway pattern help? Create a Gateway to the old database. Place all the conversion logic in the Gateway.