企业应用架构模式及关于软件架构的思考.pptVIP

提纲 领域逻辑在代码中的安排 领域对象与数据库表的交互 事务处理和并发 分布策略 延迟加载 对象-关系结构模式的几点思考 一些感悟 领域逻辑在代码中的安排 领域逻辑在代码中如何与GUI（表现逻辑）、远程调用外观、数据库访问（数据源逻辑）进行分离 客户端领域逻辑与表现逻辑的分离 服务端领域逻辑的代码安排 客户端领域逻辑与表现逻辑的分离 不要将过多的领域逻辑直接写在GUI类的onAction()方法中，代码应该做到类层次上的分离，用独立的类编写和维护领域逻辑 建议将输入值检查、客户端数据缓存，放入领域逻辑类，而不是GUI类 系统分析未必可以细致到这个层次，这些观念需要在详细设计和编码中充分注意 服务端领域逻辑的代码安排 我们在强调减少BO类，以降低对服务器资源的占用时，已经将BO类及其public方法越来越看作一个纯粹的远程调用外观。在这种观念下，让BO进一步承载领域逻辑的功能已经不合适。尤其是这将造成过多的，关系不大的业务逻辑写入一个过分庞大的BO类，连基本的组件划分都消失了。 DMO的字面含义为数据管理对象（其实含义模糊不清），我们主要用它来做SQL拼写、OID获取、数据库交互、加锁等等。 服务端领域逻辑的代码安排——我的建议（1） BO类仅仅保存远程调用的外壳。必要的情况下，可以一个产品仅仅保留一个BO类； DMO类务必按照不同的业务对象分拆到类，不同的节点对应的DMO应该进入不同的包，不可以在比这个更粗的粒度上相互混杂； 对于比较简单的情况，领域逻辑全部写入DMO 对于比较复杂的情况，将非数据库交互的领域逻辑进一步拆分出来，用单独的类进行管理（比如：更新应收的数据转换类，负责将单据传入的数据信息转换成更新应收算法需要的信息） 服务端领域逻辑的代码安排——我的建议（2） 鼓励在DMO类或专门的领域逻辑类中保存状态（大部分的远程调用是无状态的，但是对于一次调用内部没有限制。我们应该在服务端的业务逻辑编写中，充分利用面向对向编程的各种技巧，做成“进程内调用”的“细粒度对象”） 不建议对非本对象的表进行直接查询，如果难以避免，在这种要求较多的业务处理点，可以用单独的“服务类”处理这些独立查询，和领域逻辑的处理代码相分离，以达到领域逻辑清晰、稳定的目标（举例：更新应收代码中，为获取应收单上游发票的冲减前单价、销售出库单源头的销售订单产品线等等） 领域对象与数据库表的交互 系统现状 “阻抗不匹配”问题 存在的问题 数据库访问的独立化要求 领域对象与数据库表的交互——系统现状 领域逻辑和领域对象的设计完全依照面向对象的原则进行，较少考虑数据的存储方式； 数据库表结构的设计又基本是纯粹依照关系数据库的设计原则（依据范式，作信息本身持久化所需要的最小存储设计，保证数据可以以某种方式获取就可以了。有时会为查询性能对存储结构做适度调整）进行，很少考虑面向对象编程的特性，和领域对象自身的业务要求 举例：信用系统，数据库存储应收每日发生数据，DSO查询却需要每天的应收余额。为数据存储的简单，设计为存储每日发生，承受的代价是查询之后的数据处理算法比较复杂。 领域对象与数据库表的交互 ——“阻抗不匹配”问题 这基本上是书本上认为最为困难的一种匹配，因为在这种模式下领域对象和数据库对象的关系处理起来非常麻烦——“阻抗不匹配”问题 ： 对象通过在运行时保存引用的方式处理连接，由上层对象管理关系（聚合）；数据库通过存储另外一个表的键值处理连接，由下层保存关系。所以对象和表之间的数据结构是颠倒的 关系数据库存储多对多关系的麻烦：一般是用一张独立的关系表存储的。但是对象不会这样处理 面向对象的语言中， 通常使用数组、列表这样的有序集合，但是在数据库中，想保持一种顺序要困难得多 领域对象与数据库表的交互 ——存在的问题 不可避免的在业务代码中存在大量的“数据整理算法”，其实是在处理这种转换：更多是从查询结果集转换到对象，也有从对象整理出来准备持久化 领域模型模式往往伴随着“非常杂乱无章的数据库连接”。确实，在我们的代码中，领域逻辑和数据库访问完全相互混杂，几乎没有办法拆解，查询——结果集整理——领域逻辑——返回，或再存储，等等。以至于从代码中搜索SQL语句几乎是不可能的事情。我们真的是SQL高手，以至于可以对这种做法充分放心了吗？ 领域对象与数据库表的交互——数据库访问的独立化要求 作者观点：“把SQL访问从领域逻辑中分离出来，并把它放到独立类中” 对于我们当前的工作环境和工作要求，我并未想出可操作的执行办法，和强行要求这样做的理由。好像也不是非常现实。但或许这是我们可以努力的一个方向。 事务处理和并发 锁 短事务原则 事务处理注意事项 事务处理和并发——锁（1