PoEAA笔记-映射到关系数据库-3.5 建立映射

3.5 建立映射

如果在使用领域模型，应该小心那种看上去像数据库设计的设计。在这种情况下，建立领域模型不用理会数据库，这样可以简化领域逻辑。把数据库设计看作一种持久化对象数据的方法，数据映射器非常灵活，当然也带来了复杂性，如果数据库设计和领域模型同构有意义，可以考虑使用活动记录来代替。

尽管首先建立模型是一种合理的方法，但这个建议仅仅是用于短的迭代周期内，花费6个月的时间建立一个没有数据库的领域模型，并且决定一旦完成就持久化它。这是一件非仓冒险的事情，危险在于，设计结果会因为你迫切的性能问题而需要进行很多重构来修复。相反，应该为每一次迭代建造数据库，时间上不要超过6个月并且适当的更短一些，这样就能更快和更持续的得到关于数据库交互实际上如何工作的反馈，针对特定任务，都应该首先考虑领域模型，但是这样做的时候，需要在数据库中集成领域模型的每一部分。

当已经存在一个数据库方案的时候，选择很相似，但过程却有点不同，对于简单的领域逻辑，可以建造行数据入口和表数据入口来模拟数据库，并在此之上构建领域逻辑

双向映射

有时，我会遇到这种情况：同样的一种数据却需要从不止一饿数据源上取出来，可能有多个数据库保存相同的数据，只是由于某种复制和粘贴的重用会导致在数据库方案上的一些细微区别。（在这种情况下，头痛的数量域区别的数量成反比）另一种可能是使用不同的存储机制，有时是数据库，有时是消息，也可能希望把类似的数据同时从XML消息，CICS事务和关系表中抽取出来。

最简单的选择是建立多个映射层，每个数据源一个，然而如果数据非常类似的话，就会导致过多的复制。在这种情况下，可以考虑两步映射策略。第一步把数据从内存方案中转化到逻辑数据存储方案。设计逻辑数据存储方案是用来最大化数据源格式中的相似之处。第二步映射从逻辑数据存储方案到实际物理存储方案。第二步包含区别

当有许多共同点时，额外的步骤仅仅补偿它们自身，因此你应该在有相似但又有十分头疼的不同的物理数据存储时使用它。把从逻辑数据存储到无力数据存储的映射看成时一个入口，并且使用任何映射技术从应用程序逻辑映射到逻辑数据存储。

个人体验：设计时应把精力集中到领域模型，甩开数据库。但应该为每一个迭代建立数据库，这样可以得到持续的反馈。