::Z::Thinking::

::Simple::
文章 - 124,收藏 - , 评论 - 49, trackbacks - 0
No silver bullet

设计方法的分类:

1. 结构化设计(自顶向下)——没有提供适当的方法解决并发性问题。
2. 数据驱动设计——广泛应用于信息管理系统,它关注系统的输入输出。
3. 面向对象设计——适应复杂开发并具有良好复用性。

面向对象的本质:抽象封装多态继承。第一要着的抽象是不确定的,它具有层次,可以排列成为一种层次
框架——软件复用的发展方式:程序主体反主为客,并让辅助组件反客为主,即控制反转。如果一个程序库负担了整个应用程序来于运行的主干算法,并实现了主动的事件循环事件处理机制控制流程。则为框架。

所谓的应用架构的外在本质是把“技术问题和业务问题分离”,而其内在本质是抽象,把一个系统抽象为技术和业务。以达到技术的复用。任何一个系统都存在技术问题,虽然他们的业务问题可能不一样。

技术层面上,建立一个应用架构从宏观层面来看第一要著是使系统结构化,结构化的途径有三个:分层管道和过虑黑板

  1. 分层模式是一种解决打系统的良好的方法,无论是J2EE还是.Net都应用这种技术。本质上讲分层是抽象的排列。因为大系统复杂性较高,它的抽象层面也相应较多。
  2. 管道和过虑通过用来解决数据流的较好方式。
  3. 黑板则是用来解决不确定性问题的首要途径。当一个问题解决方法缺乏一定模式,而现有的方法集中的每个方法都只能解决问题的一个部分,并各自不相交。黑板可以成为较好的抽象机制。

因此开发一个应用系统,分层成为设计的首先。以下将详细讨论分层模式下的抽象机制:

(图1)

数据访问逻辑层采用domain model,同时使用object/relational mapping pattern的Data mapper pattern和active record pattern向上提供数据访问服务。而在Data mapper和active record中进行concurrency pattern进行并发性控制。
如下图:

(图2)

业务逻辑层分成三个部分,如下图:

(图3)

基础:

1. 业务实体由实体集和实体组成,这些来自数据访问逻辑层。

2. 业务规则定义了对业务实体内部关系,以及业务实体间的关系。
   1.业务实体内部关系:(除非只有一个规则,否则)可以采用职责链模式。(这样可以避免过多的条件判断。)
   2.业务实体外部关系:
       2.1 非强制一对多:可以采用职责链模式。(这样可以避免过多的条件判断。)
       2.2 强制一对多:采用observer观察者模式。
       2.3 多对一:可以采用mediator中介者模式。

3. 业务外观把业务实体和业务规则统一起来。

中级:

1. 考虑一个业务规则,其有严格的限制,联系到多个业务对象,同时其关系成网状,例如:一个实体的方法实现必须满足多个实体的状态值,大量的条件判断不可避免。当系统复杂性提高时,网状的关系将不可避免。此时采用以上简单的方法不能满足要求。这时采用扩展有限状态机来实现将可以解决问题。
2. 业务外观层联系实体和规则,当业务的流程性很强时可以采用工作流技术。同时无论是否采用工作流技术,但系统复杂性提高时,应该采用扩展有限状态机来做控制系统。

高级:

1. 业务规则和业务外观的外在本质上是一个控制系统。业务规则实现状态的转换,而业务外观委派状态的行为。
在业务规则层采用传统方法设计,将不可避免得造成如下之一的情况:1. 控制器庞大而条件判断过多; 2. 产生多个控制系统;3. 多态后系统控制系统之间继续关联关系复杂。造成控制系统维护的困难性提高。 而解决方案就是: 有限状态机。作为一个严格的数学模型,其在状态转换的控制上有明显的优势。



Trackback: http://tb.donews.net/TrackBack.aspx?PostId=36296


[点击此处收藏本文]  发表于2004年07月01日 5:31 PM




正在读取评论……