与struts的亲密接触
当时上网看招聘信息，j2ee相关职位的都要求懂struts。看来学习struts是势在必行了。Struts的确是当时最优秀的框架，开发人员再也不用对每个方法都写一个servlet类了。请求成功或失败后的页面跳转不用写死在代码中，而是可以通过struts-config.xml来进行配置，表单组件可以自动的绑定成actionForm对象。还可以自定义数据校验逻辑。Struts还提供了一个通用的数据校验框架.struts还提供了丰富的显示标签。主要的时间都花在标签的学习上了。Struts显示标签比时当时的jsp 表达式的确是一大进步了。在jsp页面，不达再写’<% %>’这些表过式语言了，而是使用像html那样的标签。当jstl出现后，jstl的类似c语言似的标记语言要比struts显示标答优秀得多。Struts显示标签不能自动处理null值问题，struts显示标签还是显得太复杂了，花那么大的力气去学习struts显示标签显然是很不值的一件事！
我用jsp+servlet开发的时间要比用struts进行开发的时间长得多，但是struts的确是一个非常优秀的框架。
基于html: web应用是基于html的，不管是jsp还是asp，asp.net还是jsf都是在服务器端把相应的代码解释成html代码，然后在客户端通过浏览器解析显示出来。
无状态编程：不管采用什么技术，web开发终竟是无状态编程。也就是在客户端并不能保持应用程序的任何状态。在swing或vb等桌面开发时，客户程序可以通过变量来保持系统的状态。而基于html的web应用是无法保持状态的。Web应用状态都需要由应用服务器来保持。
请求响应及推/拉模式：在swing或vb等桌面应用程序中，当某一状态发生改变时，后台程序可以触发系统更新前端的UI组件，甚至可以使用观察者模式，当某一状态发生改变时，通知所有需要更新的前端UI组件，加载数据刷新组件。完成UI组件的更新，用户可能没有做任何动作，这就是推模式。而web应用正好相反，用户从客户端发出一个请求，服务器接到客户端的请求后，读取请求参数，调用业务方法，获得业务数据，用业务数据重新生成新的html页面，呈现给客户端，由浏览器进行解析显示,这就是拉模式。请求响应的拉模式是web应用最大的特点，任何请求的页面在发出请求后，请求页面所有组件的状态都被刷新而无法得以保持。
MVC：MVC即model模型数据，view 视图,controller 控制器。MVC模式让每一个组件都有了一个明确的职责,模型数据不含有视图特有的代码，视图不含有控制代码或数据访问代码,主要是显示模型数据。控制器接收请求，获得数据，进行视图转发。
控制器是WEB应用中的中枢神经,web应用控制器的主要职责：校验及获取请数参数,调用业务对象进行业务处理,把从页面获得的请求参数传递给业务对象。通过业务调用获得数据或创建模型数据。在需要保持服务端状态的应用中，创建或操作session状态。创建一个视图，由视图来使用模型数据。
模型含有由视图显示的数据，在j2ee web应用中，模型一般是JavaBean。Web应用中的模型一般表示一个完整的业务操作的结果对象。这个结果对象通常不是一个真实的领域对象，而是一个只有getter,setter方法的对象(如值对象),通常称为伪数据对象。模型没有必要进行进一步的操作，如数据访问等，模型也不应该依赖Serlvet或某一WEB应用框架.
视图用于呈现模型数据，负责生成标签或其它内容。视图不需要了解控制器或业务对象。视图不应该直接处理请求参数，而是应该由控制器去做。也不应该进行数据查询，如sql查询,视图不应该处理数据查询异常。显图只需要执行必要的显示逻辑，把模型数据通过一定的逻辑呈现给用户。
Front Controller前端控制器与命令模式:采用纯Servlet和JSP的model 1进行web开发都是非常复杂的。不可能实现java开发人员与UI开发人员角色的分离。采用纯Servlet来开发web应用，如果要从serlvet这种纯java对象中配合html标记进行web开发是非常笨拙的，这样将十分难以维护。采用纯JSP来开发web应用，JSP可能很容易的嵌入html代码，并通过jsp表达式可以很容易的动成生成html内容，JSP还定义了对象的作用域。关键是可以在jsp中编写任何java代码,相比纯servlet来说，用JSP开发要轻松多了。但是把所有业务代码编写在JSP中，任然不能把java开发人员与UI开发人员进行分工。业务方法无法进行测试和重用，代码重用只能是简单的代码复制，这样的web应用仍然难以进行维护。
采用jsp+servlet的MVC模式进行开发，java开发人员负责开发servlet,而UI开发人员设计HTMl和编写JSP，每一个请求对应一个servlet，由servlet调用业务对象，获得业务数据，并选择视图进行转发。在这里JSP没有了任何业务代码，仅仅是显示数据。这样通过JSP与servlet相结合的MVC模式，可以让java开发人员与UI人员进行分工，也便于了业务代码的测试。但是每一个请求都对应一个单一的servlet,需要产生大量的servlet类，把许多方法分散到多个servlet类中，需要对相似的请求过程编写独立的方法，不能进行方法的重用。从而产生大量的重复代码，大量的servlet配置将非常烦琐。从而需要对大量的servlet进行维护。如果有一个控制器来接收所有的请求，根据请求的参数，把请求传递一个委托对象，由委托对象来完成以前控制器完成的工作。这个控制器一般由一个servlet来完成,这就是前端控制器模式。这个前端控制器作为一个web应用的处理中心，用来处理所有相关的请求，对所有请求进行集中控制。前端控制器相当于web应用的集中处理器，完成所有请求的控制，对所有请求都需要处理的逻辑可以在端控制器中完成。把请求对象传递给委托对象。这个委托对象就像以前的控制器那样工作，也就是命令模式的运用。通过这种方式，一个WEB应用只需要配置一个前端控制器（当然有必要时可以多个）,具体的控制逻辑交给委托对象去完成,我把这个委托对象称为控制器，可以很好的实现代码重用，java开发人员与UI开发人员的真正分离，让开发人员只关心真正的业务实现。业务对象是真正的pojo对象，可以方便的进行单元测试。
几乎所有WEB框架都是基于前端控制器，命令模式的MVC运用,如webwork,spring mvc,struts。