最佳实践

在讨论基本模式之前,我们先说说一个词:最佳实践

任何程序的编写都得遵循一个特定的规范。这种规范有约定俗称的例如:包名全小写,类名每个单词第一个字母大写等等等等;另外还有一些需要我们严格遵守的:例如我们写自己的servlet的时候就得继承javax.servlet.http.HttpServlet接口。

在标准之上的是对不同标准的具体实现。例如同是servlet标准,tomcat有一套实现方式,Websphere又有不同的实现方式。
在程序员级别来说,面对复杂的业务流程,不同的程序员会有不同的实现方式。这就是程序的差异性,我们不否则差异性有点时候能提升效率,但是这种差异在更多的时候带来的是维护的难度的增加。尽管业务是不同的,具体的底层代码实现也肯定是不同的,但是出于对可维护性和可读性的要求,我们还是希望系统从代码之上的架构层次(宏观层面)看上去是一致的。这个目标我们就称之为最佳实践。
总而言之:最佳实践,就是无数程序员经过无数次的探索,尝试后,总结出来的处理特定问题的一套特定方法。如果我们把每个程序员的自由发挥作为通往成功的一条道路,那么先辈们已经总结出来的最佳实践,就是其中最短的捷径。

但是我们还是得说:尽管程序界已经有了很多的最佳实践,例如spring,hibernate,但是我们的系统又是各不相同的,我们绝对不能生搬硬套,能打开真理的锁的钥匙永远都是那把最合适的。

程序的设计是一门艺术,我们面对的大部分问题都没有一个绝对的最好的优于一切的方法。最多的情况都是这样,这种方案也好,那种方案也不错,此时我们就需要找一个"最合适的"。
目前我们能用到的几个最佳实践就包括:
始终保持程序的可读性,可扩展性,可维护性;
简单是美
尽量使用面向对象的思想
减少依赖

分层开发模式

我们谈的web开发的基本模式其实就是分层开发模式。
所谓的分层开发模式就是指在开发j2ee程序时,将整个程序根据功能职责进行纵向划分。
那么为什么要分层?
分层的原始驱动力也是我们之前说的对程序的可读性与可扩展性的追求。
只有把不同的功能职责的代码分开,才能使程序更加清晰明了------可读
把相似的功能归结为一个为一个纵向曾经,才使得在这个层次上研究一种通用的解决方案成为可能-----可扩展
最典型的划分方式就是将整个程序分为:表现层(Presentation Layer),业务层(Business Layer),持久层(Persistent Layer)
如下:

不同的层次,分配着不同的任务
表现层: 负责处理与用户交互的相关功能
业务层: 负责负责的业务逻辑计算与判断
持久层: 负责将业务数据进行持久化存储
不过在讨论分层的时候,我们又不得不面对两个问题
一 是否有必要分层?
二 如果分层,分几层?
先说第一个问题,如果项目很小,确实就没有必要分层了,就是俗话说的"杀鸡焉用牛刀""高射炮打蚊子";不过如果项目很大,牵扯到各个方面,那么此时使用分层开发模式就是是有意义的。
第二 如果分层,分几层?之前说了有一个最佳实践是"简单是美"所以我们希望将分层做的简单。但是实际上,对这个问题也没有绝对打答案,因为一切脱离了业务实际的架构设计都是虚幻的我们只能在实践中不断地摸索,把前人的经验作为我们程序分的重要依据。
其实我们所熟知的那些框架就是针对各个开发层次的编程问题而设计的解决方案。
例如 spring服务于业务层,hibernate服务于持久层,struts就工作再表现层。

MVC模式

在分层开发的前提下,每一层我们都可以拿出来单独研究并寻找最佳实践。对于表现层来说,MVC模式被广泛的应用,并且在此基础上创建了许多成熟的框架。(MVC是一种思想,而不是一种技术,它本身并不是代码,就像我们在程序中说的接口,记住,它只是一种思想而已)
M(Model)----数据模型
V(View)----视图展现
C(Control)----控制器
所谓的mvc模式就是通过元素分解来处理基于"请求----响应"模式的程序的开发中遇到的问题。
任何一个B/S应用,其本质就是一个"请求----响应"的处理过程集合体。
现在我们看看"请求----响应"的过程。


在图中,至少有三个元素是不可或缺的:
数据模型:
在图中就是顺着箭头方向进行传输的数据,他们是程序的核心载体。
对外交互:
我们可以理解我两部分,一个"头",一个"尾"。头是我们一切请求的开始,没有头,后面的一切都无从谈起;尾是最后的表现,我们得告诉系统外部的观察者我们最终的执行结果。
程序的执行和控制:
它不仅接受请求,也要处理请求,并且在处理完后还要负责相应跳转。

在很久之前,我们使用servlet来作为程序的执行和控制部分,后来我们有了struts,就使用了它所提供的action,也许几年后,struts也会走下历史舞台,我们会使用一种新的技术来作为程序的执行和控制。但是,如果我们忽略这些外在的表现形式,其内部不就是MVC吗?
数据模型-----------M
对外交互-----------V
程序的执行或控制----C
其实我们很早都这样用了,我们缺乏的只是把这个概念挖掘出来的能力而已。现在我们再看看一个经典的MVC模型图:

我们需要做的就是为这些框赋予不同的表现形式。其实框架干的就是这个事,只不过框架除了赋予上面几个元素一定的表现形式外还解决了各个元素运行起来所遇到的问题而已。

下一节,我们就先忘掉所有的框架,用最原始的方式来实现MVC模式,并且说说表示层所遇到的几个问题。