我的存储库有太多逻辑吗？

Question

我有一个遗留数据库，我的新应用程序必须与之交互。旧数据库过度规范化，一般设计不佳。例如，我的域中的一个对象表示数据库中的五个表。我希望保留我的域层免于遗留数据库中的工件。我应该在这里使用什么模式？

乍一看，我想到了Repository Pattern。我会将我的对象传递给存储库，让它处理将数据拆分为五个表。但是，有人建议必须完成的所有映射都会为存储库添加太多逻辑。那么，它存储库在这里是一个糟糕的选择？我应该使用Repository与另一种模式（如适配器）？或者Repository在这种情况下是正确的选择吗？

Answer 1

存储库模式在这里是合适的，但是如DanP所建议的那样使用Data Mapper将有助于遵守单一责任原则。诸如NHibernate和Entity Framework之类的ORM通常会促进Data Mapper的作用，但如果您的数据存储不利于使用ORM，则可以自己实现此逻辑。

Jeff Morris提供了在Repository模式here的上下文中使用Data Mapper的一个很好的例子。

但是，对于记录，ORM的工作是桥接object-relational impedance mismatch。关系数据库模式的结构通常与域模型不同。由于其他原因，您的数据库很可能设计得很差，但实体和表之间缺乏一对一的关系本身不应被理解为设计不良的指标。从DDD角度来看，数据库被视为应用程序域的持久性存储，数据库可能已针对其写入的原始域进行了适当的规范化。

Answer 2

我认为Data Mapper模式就是你所追求的。顺便提一下，您可能会在Davy Brion的this series of posts中获得关于手动滚动数据访问的一些见解。

我很感兴趣，为什么不选择像NHibernate这样的东西而不是自己做所有肮脏的工作？

Answer 3

网关模式可能有帮助吗？创建旧数据库的网关。将所有转换逻辑放在网关中。