企业应用架构模式

按有用程度 按页码先后 最新笔记

• 

  第166页

  TonySeek

  

  最近读 Martin Folwer 的《企业应用架构模式》，其中对于关系型数据库与对象模型的同步问题，提到了使用 DataMapper 和工作单元来协调。 而关系型数据库的数据储存和对象模型的差异在于，关系型数据库是不允许集合类型存在的。在典型的 1 - N 关系模式中，是由 N 来保存对 1 的引用（数据库中体现为外键）；而在对象模型中， 1 - N 的聚集关系是由 1 来保存 N 的集合。也就是说，数据映射层的一个职责，是完成这个“翻转”过程.. (更多)

  最近读 Martin Folwer 的《企业应用架构模式》，其中对于关系型数据库与对象模型的同步问题，提到了使用 DataMapper 和工作单元来协调。

  而关系型数据库的数据储存和对象模型的差异在于，关系型数据库是不允许集合类型存在的。在典型的 1 - N 关系模式中，是由 N 来保存对 1 的引用（数据库中体现为外键）；而在对象模型中， 1 - N 的聚集关系是由 1 来保存 N 的集合。也就是说，数据映射层的一个职责，是完成这个“翻转”过程。

  完成这个“翻转”并不复杂，我的做法是在 DataMapper 中保存一个哈希表，用于记录外键值（也可以保存在领域对象中，但我设计 DataMapper 时尽量不入侵领域对象，对领域模型层保持最小获知）。然后在工作单元提交同步请求时，将各个对象内部的集合同步到这个哈希表中。最后在数据库操作时简单的从该哈希表得到外键值写入即可。

  这种做法看似简单，但有一个致命的缺陷。问题就出在工作单元。工作单元在一个对象从数据库进入上下文的时候（find 阶段），是为这个对象克隆了一个副本作为原型保存的。工作单元提交时，将各个对象和它的原型对比，据此确定对象是否已被修改（dirty 对象），如果是 dirty 则交给对应的映射器执行 update 。

  
  1 - N 关系模式与对象聚集

  但正如上图，在 A 聚集 B 的情况下，如果 A 中聚集 B 的集合发生修改，则 A 会被标记为 dirty。但此时对 A 执行 update 并不能真正保存集合的修改，因为数据库中外键是属于 B 的。也就是说，被标记为 dirty 的 A 并不足以表示 A 是否真的需要同步，而真正需要同步的 B 却不能正确的收到同步信息。

  类似的问题还有 N - N 模式下，多对多的对象关系。在关系型数据库中，这要借助中间表保存信息。而如下图：

  
  N - N 关系模式与对象相互聚集

  无论是 A 还是 B 被标记 dirty，对 A、B 的同步并不能记录下信息，真正需要的是同步中间表。

  种种麻烦，根源均在于“外键”的特殊性。从外键到集合，或从集合到外键，是我们的 ORM 需要“映射”的地方。所以，我想比较妥当的解决方案是记录下“外键”。也就是在数据表的元信息中标记出外键，以便识别做特殊处理。

  而在工作单元提交同步请求的时候，应该先将所有涉及对象执行“同步外键”的操作，将关系模式转换。而在标记 dirty 的部分，应该把待同步对象做一个副本，unset 或用空数组覆盖掉其中集合性质的属性，然后再做对比，避免因集合类型的改变而把不该标记为 dirty 的对象标记为了 dirty；再取出元信息中所有外键，检查其值是否修改。将两批检查结果做 AND 运算，得出真正的 dirty 集合。再行进行数据库同步。

  这种处理思路是：先转换模式（映射），再检查 dirty，最后同步。

  另附上工作单元对于新对象、clean 对象、dirty 对象处理原理：

  
  工作单元运行原理

  (收起)

  2011-07-18 01:28:17   回应

  收藏

  推荐
• 

  第2页

  朱震轩 (keep reading)

  企业应用： 持久化数据 大量数据 很多人同时访问数据 大量操作数据的用户界面屏幕 与散布在企业周围的其他企业应用集成 概念不一致性 复杂的业务“无逻辑” (更多)

  企业应用：

  持久化数据

  大量数据

  很多人同时访问数据

  大量操作数据的用户界面屏幕

  与散布在企业周围的其他企业应用集成

  概念不一致性

  复杂的业务“无逻辑” (收起)

  2011-06-11 17:04:03   回应

  收藏

  推荐
• 

  第1页

  朱震轩 (keep reading)

  构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。 (更多)

  构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。

  (收起)

  2011-06-11 17:03:12   回应

  收藏

  推荐

• 

  第1页

  朱震轩 (keep reading)

  模式描述在我们周围不断重复发生的问题，以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。 ——Christopher Alexander 企业应用在某些方面比其他软件复杂得多（如电信通信软件）：纷繁复杂的企业数据、“不合逻辑”的业务规则、变化莫测的用户需求，等等。 模式的关键点在于它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出‘这些解决方案的核心’。这不是一个简单的过程.. (更多)

  模式描述在我们周围不断重复发生的问题，以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。 ——Christopher Alexander 企业应用在某些方面比其他软件复杂得多（如电信通信软件）：纷繁复杂的企业数据、“不合逻辑”的业务规则、变化莫测的用户需求，等等。 模式的关键点在于它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出‘这些解决方案的核心’。这不是一个简单的过程，但是一旦发现了某个模式，它将是非常有价值的。

  (收起)

  2011-06-09 15:52:12   回应

  收藏

  推荐
• 

  第1页

  朱震轩 (keep reading)

  构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。 (更多)

  构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。

  (收起)

  2011-06-11 17:03:12   回应

  收藏

  推荐
• 

  第2页

  朱震轩 (keep reading)

  企业应用： 持久化数据 大量数据 很多人同时访问数据 大量操作数据的用户界面屏幕 与散布在企业周围的其他企业应用集成 概念不一致性 复杂的业务“无逻辑” (更多)

  企业应用：

  持久化数据

  大量数据

  很多人同时访问数据

  大量操作数据的用户界面屏幕

  与散布在企业周围的其他企业应用集成

  概念不一致性

  复杂的业务“无逻辑” (收起)

  2011-06-11 17:04:03   回应

  收藏

  推荐

• 

  第166页

  TonySeek

  

  最近读 Martin Folwer 的《企业应用架构模式》，其中对于关系型数据库与对象模型的同步问题，提到了使用 DataMapper 和工作单元来协调。 而关系型数据库的数据储存和对象模型的差异在于，关系型数据库是不允许集合类型存在的。在典型的 1 - N 关系模式中，是由 N 来保存对 1 的引用（数据库中体现为外键）；而在对象模型中， 1 - N 的聚集关系是由 1 来保存 N 的集合。也就是说，数据映射层的一个职责，是完成这个“翻转”过程.. (更多)

  最近读 Martin Folwer 的《企业应用架构模式》，其中对于关系型数据库与对象模型的同步问题，提到了使用 DataMapper 和工作单元来协调。

  而关系型数据库的数据储存和对象模型的差异在于，关系型数据库是不允许集合类型存在的。在典型的 1 - N 关系模式中，是由 N 来保存对 1 的引用（数据库中体现为外键）；而在对象模型中， 1 - N 的聚集关系是由 1 来保存 N 的集合。也就是说，数据映射层的一个职责，是完成这个“翻转”过程。

  完成这个“翻转”并不复杂，我的做法是在 DataMapper 中保存一个哈希表，用于记录外键值（也可以保存在领域对象中，但我设计 DataMapper 时尽量不入侵领域对象，对领域模型层保持最小获知）。然后在工作单元提交同步请求时，将各个对象内部的集合同步到这个哈希表中。最后在数据库操作时简单的从该哈希表得到外键值写入即可。

  这种做法看似简单，但有一个致命的缺陷。问题就出在工作单元。工作单元在一个对象从数据库进入上下文的时候（find 阶段），是为这个对象克隆了一个副本作为原型保存的。工作单元提交时，将各个对象和它的原型对比，据此确定对象是否已被修改（dirty 对象），如果是 dirty 则交给对应的映射器执行 update 。

  
  1 - N 关系模式与对象聚集

  但正如上图，在 A 聚集 B 的情况下，如果 A 中聚集 B 的集合发生修改，则 A 会被标记为 dirty。但此时对 A 执行 update 并不能真正保存集合的修改，因为数据库中外键是属于 B 的。也就是说，被标记为 dirty 的 A 并不足以表示 A 是否真的需要同步，而真正需要同步的 B 却不能正确的收到同步信息。

  类似的问题还有 N - N 模式下，多对多的对象关系。在关系型数据库中，这要借助中间表保存信息。而如下图：

  
  N - N 关系模式与对象相互聚集

  无论是 A 还是 B 被标记 dirty，对 A、B 的同步并不能记录下信息，真正需要的是同步中间表。

  种种麻烦，根源均在于“外键”的特殊性。从外键到集合，或从集合到外键，是我们的 ORM 需要“映射”的地方。所以，我想比较妥当的解决方案是记录下“外键”。也就是在数据表的元信息中标记出外键，以便识别做特殊处理。

  而在工作单元提交同步请求的时候，应该先将所有涉及对象执行“同步外键”的操作，将关系模式转换。而在标记 dirty 的部分，应该把待同步对象做一个副本，unset 或用空数组覆盖掉其中集合性质的属性，然后再做对比，避免因集合类型的改变而把不该标记为 dirty 的对象标记为了 dirty；再取出元信息中所有外键，检查其值是否修改。将两批检查结果做 AND 运算，得出真正的 dirty 集合。再行进行数据库同步。

  这种处理思路是：先转换模式（映射），再检查 dirty，最后同步。

  另附上工作单元对于新对象、clean 对象、dirty 对象处理原理：

  
  工作单元运行原理

  (收起)

  2011-07-18 01:28:17   回应

  收藏

  推荐
• 

  第2页

  朱震轩 (keep reading)

  企业应用： 持久化数据 大量数据 很多人同时访问数据 大量操作数据的用户界面屏幕 与散布在企业周围的其他企业应用集成 概念不一致性 复杂的业务“无逻辑” (更多)

  企业应用：

  持久化数据

  大量数据

  很多人同时访问数据

  大量操作数据的用户界面屏幕

  与散布在企业周围的其他企业应用集成

  概念不一致性

  复杂的业务“无逻辑” (收起)

  2011-06-11 17:04:03   回应

  收藏

  推荐
• 

  第1页

  朱震轩 (keep reading)

  构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。 (更多)

  构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。

  (收起)

  2011-06-11 17:03:12   回应

  收藏

  推荐