12 2010 档案
摘要:上篇文章《OEA中的AutoUI重构(2)- 评审会议前的总体设计》写了在“OEA框架”中进行AutoUI模块重构的设计方案。最近项目组已经召开了评审会议,并对该设计进行了审核、建议。本篇文章主要记录其中一些主要的改动。 设计改动 大家认为 AggregateBlocks 和 BlockDefinition 的设计过于复杂,不易于理解。考虑的东西太多,有过度设计之嫌,所以这一处的设计改为使用Composite模式来组合“UI块”: 另外,上次的设计中,有一个小错误:不应该把元模型的仓储 UIInfoRepository 放在单个的界面组成单元中,而是应该放在更上层的整个界面的元模型层。 相应
阅读全文
摘要:今天参加了一年一度的《中国软件工程大会》,听了许多前辈在台上精彩的演讲,自己也有很多感触。接下来,我会先把几个重要的演讲总结一下,最后再写一个自己的心得。项目经理领导力演讲者:田俊国领导力和领导二者并没有直接关系。很多名为领导的人,常常被下属牵着鼻子跑。达成共识、目标共享一个搬梯子的故事形象地解释了和下属共享目标的重要性。要做冰山下的沟通一座冰山,只有很少的一部分是露在水面上的。如果只做表面的沟通,往往不是最直接的,也不能很好地达到沟通的目的。做一个高自尊的人气球原理要当领导,至少你的气球要能包容你下属的气球。做好教练势利权形情类似于金木水火土、仁义理智信。软件企业常见问题和系统性解决方案 演
阅读全文
摘要:之前已经写了一篇关于其中Command模块的重构:《OEA中AutoUI重构(1) - Command自动生成》。Command自动生成的重构作为本次重构的一个“前锋战”,尝试用OO的方式把原来的过程式的界面自动生成流程进行优化,以支持更好的可扩展性。Command自动生成较为独立,所以就单独先进行了重构,目前重构已经完成,效果较好:和原有系统完成兼容,同时插入了更多必需的扩展点。 本次重构主要...
阅读全文
摘要:现象 这个月我的工作任务中,有一项是重构OEA框架中的AutoUI部分。这个任务在月初时计划在一个月内完成,包括问题分析、设计新的结构、编写设计文档、开展设计评审、代码实现。原计划半天到一天的评审会议,最后花费了大概一天半的时间。接下来,我就评审会议中出现的问题进行一下总结。 本次AutoUI设计是我到公司以来,觉得最有挑战的一次工作。 会议之前,我和组内的人员进行了多次沟通,了解他们的需求:我们的AutoUI框架当前有些什么问题?当界面需求被提出后,我们对它的完成情况怎么样?开发人员对AutoUI有什么期望?测试、需求人员对AutoUI有什么期望?布局有什么问题?期望的GIX4界面是什么
阅读全文
摘要:OEA框架的核心之一是AutoUI,其职责是面向领域模型及UI元模型进行生成统一的界面。 在本次的迭代开发中,需要对命令按钮的生成方式进行一些定制。由于原来并没有为这样的需求留有特别的扩展点,加之原来的生成代码是过程式的代码、且也变得比较冗长,所以我们决定对这一部分的代码进行重构。 原来的模式 历史代码中,为某一实体类生成命令按钮的流程是这样的: 找到实体类可用的所有命令按钮元数据。 对它们进行过滤,依靠权限、版本的客户化元信息等。 构造几个生成控件的List容器,分别是:itemsInToolbar,itemsInContextMenu,itemsInGroup。 遍历所有的命令按钮,根据.
阅读全文
摘要:本篇博客简单描述了Repository模式在OEA中的应用。 不使用Repository时的问题 OEA框架中使用了DDD的思想,面向领域对象进行开发。在DDD中,有很多重要的概念,例如:聚合实体对象、值对象、仓储、工厂、服务等。(不太了解的Repository和DDD的朋友,可以看Evans写的《Domain Driven Design》。) 在OEA中,实体的实现框架使用了CSLA分布式框架。原来为了简单并保持和CSLA开发模式的兼容,一直都把实体的获取模式直接以静态方法的方式直接写在实体的对应列表类中。例如下面这段代码: 随着应用的慢慢深入,出现了一些问题: 不易支持客户化。OEA
阅读全文