亚洲精品天堂成人片AV在线播放,亚洲国产综合无码一区,99久久国产亚洲综合精品

�Ҏ��编�E�原�?1)

��越巅峰 — Mon, 14 Sep 2009 12:28:00 GMT

1 SRP

SRP(Single Responsible Principle), 单一职责原则�Q�这是面对的最基本原则�Q�也是实现弹性设计的最基本原则�?/font>

每个�c�L��接口定义应该只包含一�U�明��的职责�Q�同时仅有一�U�原因会��D��q�种定义的修攏V��一个复杂的�c�L��接口的定义包含多个责任，很容易��你的设计失去�Ҏ��，很多因素都会��D��q�个�c�L��接口的变��_��׃��它含有多�U�职责，�q�就意味着它是多种服务的提供者，会有多种依赖于它的客��L��Q�他的变更可能会��D��大范围的变更�?/span>

在作者看来，优先�U�最高的是你首先要保证接口的单一职责及方法的单一职责�Q�接口通常意味可以更换不同的实玎ͼ��Z��个接口定义过多的职责意味着每个实现都会涉及多个职责�Q�这��导致无法实现更��粒度的实现的复用�?/span>

2 面向抽象�~�成

如果你已�l�读�q?font face="Times New Roman">GOF的《设计模式》，你便知道其中每一个模式都是基于此原则的，抽象�Q�或接口�Q�有效的解除了服务调用者和服务提供者间的耦合�?/font>

3 使用配置

通过修改配置文�g便可以改变系�l�的某些�Ҏ��，�q�种修改的区别于修改代码�Q�对�?font face="Times New Roman">Java,C++而言�q�种修改是不需要编译，有的修改甚至可以在运行时生效�?/font>DSL地运用可以��配置更加��h��可读性及更强的描�q�能力。在设计时将实现分�ؓ配置及框枉��分是非常灉|��的结构�?/font>

蔡超
HP 软�g架构�?br /> 软�g架构��N��
SCEA
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn

��越巅峰 2009-09-14 20:28 发表评论

��M��W�记�Q�额外的间接�?Beautiful Code)

��越巅峰 — Tue, 19 May 2009 13:45:00 GMT

�?/span>OO中可以��用抽象方法及接口来完成文中通过函数指针和结构体来实现的间接层�?br />

Client.java

AppInterface app=new AppImpl();

AppInterface app1=new AppProxy(app);

AppProxy.java

public class AppProxy implements AppInterface{

private AppInterface appRef;

public AppProxy(AppInterface appRef){

this.appRef=appRef

}

public void doSomething(){

/*some codes*/

}

通过Proxy来实现间接层�Q�相互嵌套可以实现多个间接层�Q��ƈ且可以通过一�?/span>AppBuilder来创��个对象，�l�合多个间接层。间接层中可以实现文中提及的对参数的预处理�?/span>

同时�Q�我也认为文中提及的间接层也可以�?/span>Adapter�?/span>

��越巅峰 2009-05-19 21:45 发表评论

Double Dispatch模式

��越巅峰 — Thu, 19 Feb 2009 13:02:00 GMT

本文介绍了常见面向对象语�a��Q�Java,C#�{�）OverLoad对于�q�行时执行的�Ҏ��邦定的局限，�q�且如何通过Double Dispatch来实现运行时行�ؓ邦定�?/font>

1 �Ҏ��对象来选择行�ؓ问题

public interface Event {

}

public class BlueEvent implements Event {

}

public class RedEvent implements Event {

}

public class Handler {

public void handle(Event event){

System.out.println("It is event");

}

public void handle(RedEvent event){

System.out.println("It is RedEvent");

}

public void handle(BlueEvent event){

System.out.println("It is BlueEvent");

}

public class Main {

public static void main(String[] args) {

Event evt=new BlueEvent();

new Handler().handle(evt);

}

你认��行结果是什么呢�Q?/font>

�l�果�Q?/font>It is event

是不是有点出乎意料，不是It is BlueEvent�Q�这是应为Overload�q�不支持在运行时�Ҏ��参数的运行时�c�d��来帮定方法，所以要执行哪个�Ҏ��是在�~�译时就选定了的�?/font>

2 Double Dispatch Pattern

�׃��Java,C++及C#都具有上�q�局限，通常我们只能通过Switch或if�l�构来实玎ͼ�当然�q�种实现方式既不优雅而且影响代码的可�l�护性�?/font>

通过以下的Double Dispatch Pattern便可以优雅的实现�?/font>

public interface Event {

public void injectHandler(EventHandler v);

}

public class BlueEvent implements Event {

public void injectHandler(EventHandler v) {

v.handle(this);

}

public class RedEvent implements Event {

public void injectHandler(EventHandler v) {

v.handle(this);

}

public class EventHandler {

public void handle(BlueEvent e){

System.out.println("It is BlueEvent");

}

public void handle(RedEvent e){

System.out.println("It is RedEvent");

}

public class Main {

public static void main(String[] args) {

Event evt=new BlueEvent();

evt.injectHandler(new EventHandler());

}

其实设计模式�Q�GoF)中的Visitor模式��是Double Dispatch的一�U�应用�?br />

蔡超
HP 软�g架构�?br /> 软�g架构��N��
SCEA,SCBCD,MCSD
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn,chao.cai@hp.com

��越巅峰 2009-02-19 21:02 发表评论

OSGi实现动态特性的关键模式

��越巅峰 — Wed, 15 Oct 2008 13:40:00 GMT

OSGi�q�_��为我们提供了强大的动态特性，通过分析我们可以发现�q�些动态特性的实现与很多常用的设计模式相关�Q�了解其中原理直接将�q�些模式用于我们的应用开发，也可以有效地实现动态特性�?br /> 1 Broker模式�Q�实现服务提供者与服务使用者的分离及解耦。Bundle通过所能提供的服务��自己注册至Framework�Q�调用者通过Framework查找所需的服务。Bundle的服务注册是实现服务自动发现的基��?br />
2 监听者模式：�q�是实现动态特性的关键�Q�通过监听者模式服务的使用�?实现监听接口)可以获得所依赖的服务提供者（Bundle�Q�的状态变化的通知�Q�从而动态处理与服务提供者间的关�p�M��实现动态特性，不仅如此OSGi Framework自��n同样有效的融合了�q�种通知机制�Q��得实现监听者接口的Bundle可以了解Framework的状态变化�?br />
在我们的应用�pȝ��中借鉴OSGi的原理，同样可以有效地实现动态特性�?br />

蔡超
软�g架构�?br /> 软�g架构��N��
SCEA,SCBCD
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn

��越巅峰 2008-10-15 21:40 发表评论

��越巅峰 — Wed, 25 Jun 2008 13:49:00 GMT

DAO看似是一个非常简单的模式�Q�但�q�个模式却十分重要，它可以帮助我们实现持久化逻辑和业务逻辑的分��；它可以帮助我们实现对多种持久化实现的支持�?br /> 同时�Q�DAO模式�q�没有看��h��q�么��单，要真正发挥它的威力需注意的方面很多，而这些方面常常被大家忽略�Q�以下是本�h�ȝ��的一些最佛_��c�?br /> 1 不要在DAO上控制事务的边界
应该在Façade层控制事务的边界�Q�这样可以提高DAO的复用性，使它适用于不同的事务�{�略�?br /> 2 不要�q�分使用Checked Exception
开发者常�怼��DAO中的各种异常通通捕捉�ƈ通过Checked Exception抛出�Q�其实这是中不好的习惯，因�ؓDAO中发生的异常常常是不可恢复的�Q�如�Q�数据库�q�接问题�{�）�Q�既然如此就应该使用RuntimeException异常抛出�Q��用这�U�异常还有一个好处就是在CMP的情况下可以自动引发事务的回滚�?br /> 3 不要在DAO中处理懒加蝲问题
使用Hibernate��׃��l�常遇到懒加载问题，但是�q�个问题不应该在DAO中解冻I��q�样会媄响DAO的复用性，应�ؓ要加载那些对象域往往是和界面相关的，�q�个问题应该在Façade层中解决�Q�应��是离表现层较�q�的一层�?br />

http://dev2dev.bea.com.cn/blog/chaocai/200806/dao_24_1070.html

蔡超
软�g架构�?br /> 软�g架构��N��
SCEA
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn

��越巅峰 2008-06-25 21:49 发表评论

自己实现IoC,AOP容器源码下蝲

��越巅峰 — Tue, 27 May 2008 08:54:00 GMT

上一��相兛_��?br /> http://www.tkk7.com/chaocai/archive/2008/05/26/203020.html
源码下蝲
http://www.tkk7.com/Files/chaocai/mini-container-beta0.9-src.rar
希望对大家有帮z�Q�也期待大家的反馈！

��越巅峰 2008-05-27 16:54 发表评论

自己实现IoC,AOP容器

��越巅峰 — Mon, 26 May 2008 12:21:00 GMT

摘要: Mini-Container 开发者手�?(Mini-Container Beta 0.9, 下蝲地址�Q�http://www.tkk7.com/Files/chaocai/mini-container-beta-0.9.rar ) 蔡超软�g架构�?软�g架构咨询��N�� Chaocai2001@yahoo.com.cn �?Mini-Container... 阅读全文

��越巅峰 2008-05-26 20:21 发表评论

��越巅峰 — Tue, 15 Apr 2008 13:43:00 GMT

�q�期做了几个使用OSGi开发的应用�Q�发��C��用过�l�粒度的Bundle不会�l�项目带来�Q何好处，而很多设计�h员实际都会在使用OSGi�q�_��旉��入这个陷阱�?/span>

首先我们分析OSGi的特点及可以�l�我们应用带来的好处

1 良好的动态特�?/span>

2 更细�_�度的类装蝲控制�Q�多个版本组件在同一�q�行环境中共同运�?/span>

3 �?/span>JVM内部实现SOA�Q�我个�h倒是认�ؓOSGi所涉及的仅仅是SOA思想的一��部分）

4 DS提供�?/span>IoC支持

��h��考你的应用程序真的需要这些吗�Q?/span>

很多设计和开发�h员都会在设计和实现时忽略应用的真正需要和OSGi的复杂性，��应用的所有内部细��划分都采用Bundle实现�?/span>

而我们除了应该注意采�?/span>OSGi开发和调试带来的复杂性；同时也要明白动态特性的支持�q�不是仅仅采�?/span>OSGi�q�_��可以搞定的�Q�要真正实现动态特性必��L��意模块的启动��序无关性及对其所依赖服务的监听等�Q�这些都会大大增加系�l�实现和调试的复杂性�?/span>

其实我们应该认真分析应用是否需要这�?/span>OSGi的特性及�q�些�Ҏ��应该在应用的那些部分体玎ͼ�例如我们可以在扩展方面采�?/span>Bundle实现扩展插�g�Q�至于其它部分则不必采用�q�多�?/span>Bundles�Q�甚臛_��以采用一个大�?/span>Bundle�Q�而其内部则可以采用如Spring来帮助我们实现模块化�Q��?/span>

同时�Q�不要忘记其他的framework同样提供了很好的�l��g化的基础架构�?/span>Spring�Q?/span>Pico-Container�Q�在OSGi与其它技术�؜合时SCA同样是很好的选择�?/span>

保持应用的简单性，不要针对特定技术进行设计，而要��计选择适合的技术�?/span>

蔡超
Chaocai2001@yahoo.com.cn

JEE咨询��N��
SCEA(1.2&5)
IBM Certified OOA&D Solution Designer vUML2

��越巅峰 2008-04-15 21:43 发表评论

分层模式中的常见问题

��越巅峰 — Wed, 19 Mar 2008 13:48:00 GMT

引言

分层�l�构是目前复杂应用系�l�开发时普遍使用的模式，软�g中层之间的依赖关�pȝ��束是比较宽松的，�q�不要求上层仅可以依赖于直接下层�Q�而是上层可以依赖于它的所有下层�?/div>

设计中我们会把各�U�系�l�的各种�l��g映射至不同层中，而在我所接触的一些实际项目中设计人员在映��这�U�组件和层间的关�p�L��l�常无意中破坏了层结构的依赖关系�U�束�?/div>

图表 1 典型分层�l�构

设计中的常见问题

问题一:数据传输对象�Q�DTO�Q�是否应该属于业务层�Q?/font>

在J2EE开发的�l�典著作《Core J2EE Patterns》中数据传输对象被划分在业务层模式中�Q�那么是否数据传输对象应该被映射��C��务层呢？

数据讉K��对象�Q�DAO�Q�在该著作中是被映射到整合层的，�q�样��׃��出现一个违反层依赖�U�束的问题，因�ؓ数据讉K��对象是要依赖于数据传输对象的�Q�因此下层就会出现对上层的依赖了�?/div>

所以本��为DTO是在各层中传输数据的�Q�我们可以不必强求的把他们映��到上述层次中，可以把他们放�|�在一个公共包中�?/div>

问题�?使用POJO作业务对象的轻量�U�架构与上述层模型的映射

在��用POJO的轻量��l�构中我们通常会��用持久化框架�Q�如Hibernate/JPA�Q�同时会在架构中引入仓库对象(Repository Object)�Q�负责业务对象的获取和保存。（注意�Q�他的功能和DAO是有区别的，仓库对象中通常只应包括业务对象的获取和保存逻辑�Q��?/div>

通常设计人员会把业务对象映射至业务层�Q�而将仓库对象映射��x��合层。由于仓库对象对于业务对象的依赖关系��׃��破坏依赖关系�U�束�Q�所以这�U�映��方式显然不正确�?/div>

下图是作者推荐的映射方式

图表 2 轻量�U�架构参考模�?/font>

可以看到业务对象和仓库对象都被映��至业务层，而持久化框架被映��到了整合层�?/div>

�ȝ��

因此大家在设计过�E�中不要仅仅��分层结构留于�Ş式，而要时刻注意设计是否�W�合�q�种架构模式�Q�这��h��能真正发挥这�U�架构模式的优势�?/span>

蔡超
http://dev2dev.bea.com.cn/blog/chaocai/200803/architecture_16_942.html

JavaEE 咨询��N��

SCEA (1.2&5.0)

IBM Certified Solution Designer for OOA&D UML2

��越巅峰 2008-03-19 21:48 发表评论

黑板模式的常见实现方�?

��越巅峰 — Wed, 07 Nov 2007 00:57:00 GMT

http://dev2dev.bea.com.cn/blog/chaocai/200711/06_623.html

��越巅峰 2007-11-07 08:57 发表评论

��越巅峰 — Fri, 08 Jun 2007 02:48:00 GMT

�?��?br>SCEA�Q�SCBCD�Q�MCSD�Q�IBM RUP Specilist
北京天融信��Y件架构师
SUN,Microsoft培训中心牚w��高端教师
常年提供架构咨询服务
chaocai2001@yahoo.com.cn �Q?10-82776427

问题�Q?br>在spring+hibernate的常见架构中�Q�常会应为hibernate的�g�q�加载遇��C��些麻烦。如Hibernate的引入��用脱��领域对象直接取代了DTO,然而前台组�l�显�C�时�怼�应�ؓ��q��领域对象的一些关�p�d��未被加蝲而抛出异常（其实延迟加蝲是优化系�l�性能的一�U�有效方式）�?br>��Z��使显�C�层正常工作�Q�我们就必须在业务层昑ּ�的加载这些表现层会用到的延迟加蝲的关�p�d��对象。而这��L��工作不仅需要额外的代码�Q��ƈ且这些代码往往也与所�q�行的业务逻辑无关。�ƈ且表现层的变化较多这样一来如果上�q�C��码进入业务层��׃��D��业务层跟随表现层的变化�?br>解决�Ҏ��Q?br>�?#8220;Spring构徏应用�pȝ��的最��x��构与模式实践�Q?�Q?#8221;中将逻辑层分��Z��Façade和ApplicationService两层�?br>Façade的方法组�l�是针对客户端请求的�Q�所以如果我们把业务逻辑��装在ApplicationService对象中，而把��q��对象产生�Q�包括根据表现层初始化�g�q�加载对象，关闭Session�Q�。这样便可以有效的防止表现层逻辑混入业务逻辑中�?br>

��越巅峰 2007-06-08 10:48 发表评论

Spring构徏应用�pȝ��的最��x��构与模式实践�Q?�Q?

��越巅峰 — Tue, 08 May 2007 06:25:00 GMT

�?��?br>SCEA�Q�SCBCD�Q�MCSD�Q�IBM RUP Specilist
北京天融信��Y件架构师
SUN,Microsoft培训中心牚w��高端教师
常年提供架构咨询服务
chaocai2001@yahoo.com.cn �Q?10-82776427

引言
在��用Spring构徏应用时和采用EJB构徏应用一样同样也存在不少常用模式和最佛_��践，当然很多Core J2EE Pattern仍然是我们构建spring应用中的优秀模式�Q�不�q�有的也不再适用了（如：IoC的应用��得Service Locator不再适用�Q�Hibernate取代Entity Bean使得DTO不再适用�{�）�?br>下文是一些在以Spring为核心的架构中的常见模式和架构最佛_��c�?br>
400)this.style.width=400;">

图表 1 Spring应用常见架构模式列表
DAO模式
虽然采用了诸如Hibernate�q�样的O/R Mapping工具或是iBates�q�样的SQL Mapping工具但是采用DAO模式仍有相当好处�?br>在实际应用中我们�怼�遇到如下问题�Q?br>1 性能问题�Q�由于性能问题我们可能要改变数据访问方式，如采用JDBC替换Hibernate�q�时�Q�这时如果采用了DAO模式�Q�数据访问被有效的封装和业务逻辑完全分离�Q�易于实现替换�?br>2 �U�L��问题�Q�需要支持多�U�数据库�Q�DAO模式仍然是一�U�稳妥的选择。虽然诸如Hibernate及iBates也提供很好的数据库无��x��，但如果��用某些数据库的特�D�功能时�Q�就会出现问题�?br>当然�Q�对于是否采用DAO模式也不可一概而论�Q�应��Z��毕竟会增加应用的开发复杂性。个��为很关键的一个判定条件是业务逻辑是否会和持久化逻辑混合�?br>
Application Service模式
��装一定的业务逻辑和功能，提高复用性，即防止Façade和业务对象的臃肿。注意在此可以应用Command模式及Strategy模式提供�pȝ��可维护性和可扩展性�?br>�q�个模式很重要，但常常被大家忽略�Q�这时应为我们常会把逻辑攑֜�Façade中，其实�q�是很错误的。例如：我们可能会提供多�U�不同Façade以适应不同的访问方式，�q�样��׃��出现大量重复的业务逻辑代码�?br>
Façade模式
为客��L��提供讉K��业务�l��g的统一模式。便于实现对不同讉K��方式的支持（如：�q�程或本圎ͼ�。特别在�q�程调用旉��过暴露�_�粒度的接口�Q�提高系�l�的性能�?br>同时�Q�可以根据客��L��不同�Q�通过不同Façade来控制客��L��操作�?

��越巅峰 2007-05-08 14:25 发表评论

同步代理模式 Synchronization Proxy Pattern

��越巅峰 — Fri, 10 Nov 2006 09:28:00 GMT

模式发现�?/span> : 蔡超

北京天融信，软�g架构�?/span>

SUN certified Enterprise Architect

Microsoft certified Solution Developer

IBM certified RUP Specialist

联系方式 :cai_chao@topsec.com.cn,chaocai2001@yahoo.com.cn

010-82776427

语境

在基于异步通信方式的系�l�中�Q�实现模块的同步调用�?/span>

问题

消息队列已经成�ؓ目前很多软�g选用的通讯方式�Q�消息模式��得不同分布式�l��g间的耦合性较为松散，提高了系�l�的可维护性和可扩充性。但是有时我们希望在�q�种情况下能够模拟同步的调用方式�Q�希望能够通过一个组仉��明的帮我们实现�q�种异步和同步调用的转换�?/span>

解决�Ҏ��

图表 1 ��Z��消息的分布式�pȝ��

上图是一�U�常见的��Z��消息的分布系�l�结构，�pȝ��中包含两条队列。命令队列用于传送模块间�怺�调用的命令对象，响应队列用于传送命令处理后的响应结果对象�?/span>

在通常情况下消息队列上的模块会以异步的方式工作�Q�这�U�情况下模块通常不关心命令执行后的状况，常常是不��返回值的�?/span>

��Z��模拟同步调用我们通过一�?/span> SynProxy �l��g来帮助我们完成由异步到同步调用的模拟。��?/span> Client 对其他模块的调好像是同步的一栗��?/span>

SynProxy �l��g的结构如下：

图表 2 SynProxy 的静态结�?/span>

SynProxy: �l�织完成异步到同步调用的转换

WaitingQueue: 存放�q�未获得执行�q�回值的 Command 对象

UIDCreator: 产生能够唯一标示每个 Command 对象�?/span> UID

ResponseReceiver: 监听响应队列中的响应消息�Q�它在独立的�U�程中运�?/span>

Command �Q�命令对�?/span>

Response �Q�响应对�?img height="769" alt="p3.jpg" src="http://www.tkk7.com/images/blogjava_net/chaocai/p3.jpg" width="860" border="0" />

图表 3 ��异同步调用转化成同步调用的�q�程

部分解释�Q?/span> ( 以上以在 JAVA 环境中�ؓ�?/span> )

Wait 表示调用 Command �?/span> wait �Ҏ��d��住当前线�E?/span>

Command 执行模块在执行了响应操作后生�?/span> Response 对象用于攑֛��l�果�Q?/span> Response 对象中的 UID 属性应该与处理�?/span> Command �?/span> UID 的值相�?/span>

Notify 表示调用 Command �?/span> notify �Ҏ��唤醒被阻塞的�U�程

上面�q�程中的 wait 讄��了阻塞的��时旉��Q�来自于 Command 对象的属性��|��

��越巅峰 2006-11-10 17:28 发表评论

��越巅峰 — Sat, 23 Sep 2006 04:48:00 GMT

�?/span> ��?/span>

SCEA �Q?/span> SCBCD �Q?/span> MCSD
北京天融信��Y件架构师
SUN,Microsoft培训中心牚w��高端教师

常年提供架构咨询服务

chaocai2001@yahoo.com.cn �Q?/span> 010-82776427

4+1 视图�?/span> UML

软�g架构设计已经逐渐成�ؓ��C��软�g开发过�E�的核心�Q�然而能够清晰表明架构设计�ƈ不是一件容易的事，��面向对象开发而言�Q?/span> RUP �?/span> 4+1 视图已在架构设计的撰写中得到了广泛的应用和认可�?/span>

对于 4+1 view 的描�q�有几个不同版本�Q�或包含的视图不同，或视囄��名称不同�Q�，文中�?/span> Philippe Kruchten, November 1995 提出�?/span> 4+1 视图为准�?/span>

4+1 视图包括�Q�逻辑视图�Q?/span> Logic View �Q�，开发视图（ Develop View �Q�，�q�程视图�Q?/span> Process View �Q�，物理视图�Q?/span> Physical View �Q�和场景视图�Q?/span> Scenarios �Q��?/span>

视图间的关系

4+1 视图不仅便于我们记录架构设计�Q�实际上它也指导了我们进行架构设计活动的部分�q�程�?/span>

通常我们选择 UML 来表现各�U�视图，以下列出�?/span> UML 和各视图的对应关�p?/span>

4+1 视图 UML

场景视图 use case

逻辑视图 �c�d��

开发视�?/span> �c�d��Q�组件图

�q�程视图无完全对�?/span>

部��v视图部��v�?/span>

在架构设计稳定中通常不会�l�出较多的用例描�q�ͼ��q�些是在需求稳定中定义。但是往往架构文档会选择一些用例，列入文档中，�q�些用例和一些非功能性需求一��L��以证明架构的有效和正��性。在逻辑视图中用例的实现是必不可��的一节，��管架构设计更关注非功能性需求�?/span>

融入 MDA 的思想

对于逻辑视图和开发视图所应包含的内容常常会觉得很隑֌�分两者间的明昄��限。逻辑视图包含更多的分析模型与实现技术本�w�相��x��应该较��，如业务对象模型及其扩展。而开发视囑ֈ�会与实现技术紧密相兟�?/span>

随着 MDA 思想的推�q�，在架构设计文档的撰写斚w��也��生了影响�Q�我们不难把 MDA �?/span> PIM 和逻辑视图联系��h��Q�而把 MDA 中的 PSM 和开发视图联�p��v来�?/span>

在编写逻辑视图是我们应该描�q�C��技术��^台无关的模型�Q�而开发视囑ֈ�描述与实现技术��^台相关的模型�?/span>

如在逻辑视图中表现的某些实体�c�，我们会在开发视图中转换�?/span> EJB �l��g�Q�实�?/span> Bean �Q��?/span>

�q�种做法不仅有利于我们编写架构设计文档，同时更是一�U�好的架构设计思考流�E��?/span>

��越巅峰 2006-09-23 12:48 发表评论

关于MVC模式中的通知机制

��越巅峰 — Sat, 05 Aug 2006 10:28:00 GMT

关于 MVC 模式中的通知机制

蔡超

1 MVC ��?/span>

一般应用中用户界面的变化相对较为频�J?/span> , 有时需要支持多�U�表现模式（�?/span> WEB 客户端和 GUI 客户端）�Q�但是数据和业务逻辑相对保持�E�_��?/span>

MVC(Model-View-Controller) 模式是一�U�常用的设计模式 ,MVC ��模�?/span> , 昄��和控制进行了分离�Q�可以��得应用更加方便实现对多种表现模式的支持及降低表现形式修改�Ҏ��体系�l�的影响。由于本文重点讨论的�?/span> MVC 中的通知机制�Q�至�?/span> MVC 的其它内容可以参考其它相��x��档�?/span>

图表 1 MVC 模式

2 MVC 的通知机制

上图是在 SUN �?/span> J2EE BluePrints 中关�?/span> MVC 模式的描�q?/span> , 在实�?/span> MVC 模式旉��先应该注意的是模型与视图之间的关�p�R��在�q�些关系中尤其值得大家注意的是模型通知视图�Q�如果不能正��的设计�q�个通知机制�Q�模型与视图之间兌��实现通知�Q�便会完全违�?/span> MVC 的设计初街��?/span> MVC 模式的其中一个目的在于��模式独立与视图，然而不正确的理解和设计通知机制会导致模型和试图的依赖性�?/span>

2.1 采用 Observer 模式实现通知机制

既要实现模式到视囄��通知机制�Q�同时有要确保实现模型与视图的分��R��通常我们可以通过Observer模式来实现这��L��通知机制�?br />

图表2 Observer模式

视图实现 Observer 接口�Q��ƈ向模型注册，模型通过调用所�l�护的观察者的实例调用 Update �Ҏ��来通知视图�q�行��h��。可见， Observer 接口有效的实��C��模型和视��N��的耦合性的分离�?/span>

2.2 模型通知视图�q�是控制器通知视图

图表 3 ��Z�� MVC �?/span> J2EE 应用

在将 MVC 模式应用于的��M��l�构�Ӟ��常常会有是模型通知视图�q�是控制器通知视图的问题，其实我认��个问题完全取决于对系�l�各个部分的划分和理解，如果我们把模型层更多划分为数据实�?/span> ( 如： Entity Bean) 则可能会发现�Q�其实我们的通知机制是不能由模型部分来完成的�Q�而是由我们的控制器来完成的。这�U�划分好象有些违背了 MVC 模式�Q�但实事上特别是一些想要同时支�?/span> B/S �?/span> C/S �?/span> J2EE 应用�Q�控制器和模式通知机制常常有较大的耦合性（ C/S �l�构中，客户完全通过会话 Bean 来完成业务）�Q�可能有时在一起实现更好�?/span>

��M��Q�更好的内聚性和更松散的耦合性才是架构设计的重点�Q�应该做出适合自��n应用�?/span> MVC 架构�?/span>

3 �l�束�?/font>

MVC 模式的关键在于分��L��变和不易变部分间的耦合性，所以在应用 MVC 模式时一定要注意解耦才是关键，同时一定要更据具体的��用环境进行调��_��不要生搬��套�Q�如 Microsoft �?/span> MFC 采用�?/span> Document-view ��是 MVC 的变体，它把控制器合�q�到视图中，�q�是因�ؓ考虑了视图与控制器紧耦合的媄响�?/span>

【参考文献�?/span>

1�Q?span style="font: 7pt 'Times New Roman'"> Sun Microsystem �Q?/span> J2EE BluePrints

2�Q?span style="font: 7pt 'Times New Roman'"> GOF,Design Patterns, 机械工业出版�C�， 2002

作者：蔡超

��越巅峰 2006-08-05 18:28 发表评论