.Net设计模式之外观模式
分层结构与外观模式
分层体系结构是一个时髦的话题，理论上讲，分层结构可以使系统更为清晰，更具可维护性。然而，在实践中，如果层次划分不合理，就会产生数据和功能的冗余。
需要注意的是分层的原则，即业务类负责的是业务处理，还是数据缓存。必须说明的是，层次的划分按照功能进行，而数据是在层次之间的传递。
在实现分层设计时，我们不希望层次之间有跨越；否则分层实际上没有太多意义。然而，层次之间的界面经常很难划分清楚，可以采用外观模式封装层次。在设计时可以规定，对英雄模范一层次的访问必须经过外观对象。即确保外观是层次对外的惟一接口，编程从员面对的只是其他层次的外观。这样，就保证了层次仅与相临的部分交互。
封装子系统
系统升级时，经常是一个大系统的若干子系统分别升级。这时需要封装遗留的子系统，以对外提供一个简单的接口。这种封装可以减少子系统的变化对与它接口的系统的影响，只要接口不发生变化，子系统即可作为孤立的模块升级。
在系统升级过程中，我们不主张将所有的代码升级为新的版本，如从VB 6升级到VB.NET。因为升级过程会遇到各种不确定性，这种不确定性增加了系统实施的风险，在升级体系结构，要达到这个目的，首先要封装子系统。如升级VB 6，可以将可隔离的代码封装为DLL，以被VB.NET引用。完成体系结构升级后，再逐一更新。为了降低新系统和遗留系统的耦合性，可以采用外观模式，封装接口部分的功能，仅能够通过这个接口访问遗留系统。
子系统隔离
升级与整合一个包含多个子系统的信息系统时，需要隔离这些子系统，以降低耦合性。隔离后，每个部分可以实现单独的渐进演化，整个系统的实施可以采用并行方式进行。由于各子系统只是针对外观模式界面操作，所以各个子系统的不同版本可以同时协同工作，这样便于系统的动态实施。
外观模式对于子系统间耦合强的系统尤其有用，这一点对解决实际系统的同步实施很有帮助。在实际系统的实施中，往往由于各单位无法统一安排实施时间而被一拖再拖。
系统演化
当渐进演化原有系统时，可以采用外观模式封装原系统。首先开发新系统的表示层，业务逻辑采用原有系统。然后逐步修改各个功能模块，并替换原有系统。
0
相关文章
关注我们
