第三章 J2EE设计模式
上文我们形成了对框架、模式的简单认知。作为背景知识，这一章中主要了解和理解J2EE设计模式，以期获得J2EE设计模式的全貌。由于在SUN公司的网站上有整个J2EE模式的详细的介绍，重复介绍是没有必要的。但是有张图，根据本文的内在要求，是必须要看的。从中我们会进一步漓清框架、模式、具体的技术（如J2EE技术）、设计一个应用之间的关系。
(图３)
可以这样来理解这张图片：
首先，它直接显示了J2EE技术体系中模式和模式之间的关系。在迄今的J2EE模式体系中，定型的模式就这么15种，他们分布在J2EE技术的不通层次上，相互之间通过一定的方式随着层次间的交互而交互。值得强调的是这是迄今为止的J2EE模式总揽。新的设计模式会随着实践的进一步加深而不断出现。更有意思的是模式归于层次的划分方法与抽象设计划分方法，这两种划分方法都给人有元素周期表的感觉，恐怕实际实践中也会有元素周期表的效用，促进新的模式的产生呢。
其次，它体现了J2EE技术是一种框架软件。框架可以认为是一个适用于某个领域的软件包。这个软件包提供了相应领域的各个问题的解决方法。J2EE是一种框架软件，提供了一组API，供企业级计算之用。这种框架软件的体现在了一种类似工作流的东西，一种从头到尾的企业解决方案次序。
再次，它隐含了框架与设计模式之前的血肉联系。框架是血脉、是骨架，设计模式是肉，肉依附与血脉与骨架，框架中会有各种设计模式。用体系结构的眼光来看设计模式是细粒度的元素，而框架则是粗粒度的。设计模式是支撑架构的一种重要组件，这与建筑有相象的地方，一个建筑设计时，需要建筑架构设计；施工中，用到建筑规则和模式。在J2EE整体的框架下，目前涵盖的“元素”是15种，当然没有发现的元素是客观存在的。
最后，它蕴含了应用中程序设计的理念。本质上设计一个良好可伸缩的应用本身前期工作就是设计一个框架结构。不过这种框架又是在另一层意义上的框架了。如果使用的J2EE技术，那么这就是一类在J2EE技术（框架）体系内的框架。我们基于J2EE技术可以设计许多适合更具体应用的框架。好的框架设计能够给我们带来J2EE所带来的任何好处、具备其所具有的特点；这样可以更方便的开发，更高效率的重用。即优良的框架设计往往是使用设计模式的理念，大量使用各种设计模式设计而成。实际上现在已经有很多开源组织设计的、伸缩性极强的框架结构了，比如Cocoon，Struts等。在框架内部当然可以只用到若干种、甚至不使用设计模式，毕竟设计模式只是砖头。使不使用，使用多少取决于你要建立的系统特性和你的设计理念。就是说简单的框架结构可以被固化为一次不可再扩张和重用的应用——这样的设计一般只是技术的一次应用，是没有伸缩性可言的。
第四章 把模式应用到实际项目中
模式的好处之一是让你从系统的高度分析，理解自己和别人的代码，在设计代码中获得提升自己的机会。
另外用模式的思想来设计系统会自然出现许多优点：可以获得系统设计的灵感，设计自己的框架甚至系统，现在已经有很多组织和个人在做这方面的工作，比如Struts等。可喜的是国内也出现了类似的组织。使得自己的系统更具有安全性，灵活性，可维护性——提到的每一点都能为你在更短的生命周期中开发出更多、更好的应用。
反过来说，如果你没有系统的模式思想，不用模式思想来设计系统，那很可能就会在设计自己的系统时挂一漏万，出现漏洞。下面是一个挂一漏万的例子：
[/url]这是个内部网页(电子文挡可以看到演示)，他是基于J2EE技术的一个应用，后台服务器是BEA WebLogic Server。按照安全性等要求应该只有登陆用户（而不是注册用户更不是任何用户）可以访问并使用，否则会带来垃圾信息甚至其他安全问题。所以在每个子页面应该有个安全控制机制。控制的方法是在访问的每个页面添加认证模块，这样可以保证每次页面访问的时候做一个简单的SESSION判断。如果具备J2EE设计模式的思想，解决这个问题一点也不难：[url=http://www.csdn.net/editor/Editor.htm#_第四节__前端控制器模式]前端控制器模式是个不错的选折。然而遗憾的是，任何知道绝对域名的人员和自动化程序都可以毫无约束的访问这个网页，并作一些不允许的操作,更可怕的是这些操作竟没有即使在正常情况下也该有的任何限制。
