“Struts in Action”读书有感：

“Struts in Action”读书有感：
关于JAVA WEB技术的发展：
最开始，人们通过静态的HTML来传递页面数据
随着应用的增多，许多内容不是静态的，例如：注册，密码判断，投票等带有交互性质的信息传递，通过静态的HTML显得十分麻烦
于是人们研制了CGI，CGI说白了就是通过静态的消息传递，调用操作系统中的某个程序（这个程序就是CGI）,然后CGI通过调用进行一些操作，例如判断啊，计算啊，筛选啊，等等，然后把结果返回到HTML的浏览器
但是随着一些服务器访问量的增大，不可能为每一个请求都开一个CGI程序，服务器的内存以及CPU无法应付这么大的资源消耗，于是人们又开始研究更为节省高效的机制

于是Servlet诞生了
Servlet比CGI进步的一点在于： 它针对没有请求不是新增一个程序，而是新增一个进程； 另一方面，Servlet是用JAVA写的，众所周知，因此可以跨平台（疑问： 没有用过Linux或者其他的OS使用Servlet，也不知道在Window之外它是怎么运行的）

但是随着Servlet的使用，开发人员遇到了新的问题： 那就是，很多页面上的内容，由于是直接通过Sevlet返回的，因此，在写Servlet代码中，经常需要夹带大量的页面代码，现在大家也知道，后台程序员和WEB前台工程师完全是两码事，由于网站的扩大，分工也开始明细起来。因此，虽然Servlet能够很好的解决大访问量大，跨平台等问题，但是却无法让开发团队分工更明确，使得项目的耦合度很高，于是人们又开始研究更先进的模式。
于是Struts诞生了。

需要啰嗦一下的是：事实上，在Struts诞生之前，开发人员已经开发出一种适合大访问量、业务数据复杂的网页模式，大家称之为Module 2，即使在JSP+Servlet的基础上，引入了一个JavaBean的东西作为JSP 与Servlet之前传递的中间体。为什么这么设计呢？
因为随着页面数据的复杂，许多业务数据，简单的逻辑判断，封装等等，如何实现呢？
1. 在JSP里实现。显得太为难前端开发人员了，毕竟很多前端人员是美工出身，对这些不可能了解很多。 否定。
2. 在Servlet中实现。虽然可以，但是简单的还好，如果判断和封装很复杂，大量的代码堆积在Servlet中，会不会感觉Servlet是个很杂的，很难定义的东西呢？等到后台代码也写的很复杂的时候，突然想改一改某一个模块封装的某一个字段的数据。。。从何找起？因为根本没有一个具体的类来管理这些从前台传过来的数据。否定。
所以这时候，我们用JavaBean来处理从前台JSP到后台servlet的数据交接，并且同时将数据进行封装和判断，也就是整理成后台可以立即处理的格式和内容。以此类推，当后台处理好了之后，也通过JavaBean来封装数据，传给前台JSP，则刚好是JSP可以处理的格式和类型，这样，既保证了数据前后台的统一性，也在项目代码管理上更灵活更具规模化，更为规范。
模式2就是通过JSP+JavaBean+Servlet实现的WEB网站服务器设计模式，也就是经常听到的所谓MVC模式，
M—module 意为模型，也就是封装好的数据；
V—Visual意为视图，也就是前端的页面，这里就是JSP
C—Control意为控制， 也就是后台对前端发送过来的请求进行转发，处理，然后再传回去。这里显然就是Servlet。
说了这么多，终于轮到介绍Struts了。
Struts就是在上面说到的模式2的基础上，加入了一些定制的半成品组建而形成的一个框架。这句话是什么意思呢？我们一个一个来解释。
开发人员在使用模式2的时候发现，基本上，一个WEB应用程序有很多功能是相似的，甚至可以说是重复的。不同的地方只是在于业务处理上。比如说，100个公司要建门户网站，100个公司都会有主页，注册页面，密码验证，数据查询，浏览页面等等功能。。。这些功能的实现，其实都一样，无非是各个公司的页面布局风格不同，数据类型不同，等等。如果引入一套标准的模板进行开发，岂不是更规范，效率更高？
于是在美国的一个开发团队自发的研制了一种统一的模式2模板，采用了许多订制的模板针对模式2的开发。
1. 在V层，前端，采用了一些订制的标签TLD
2. 在M层，规定使用了一个继承了一个叫做ActionForm的类来专门封装数据
3. 在C层，运用了一个叫做struts-config.xml的配置文件来反射调用M层的bean以及订制的servlet—叫做xxxxAction
并且，随着美国的那个牛B的开发团队针对世界各地开发人员遇到的问题，对产品的一步一步的优化和调整，Struts也在慢慢的版本升级，从最初的Struts 1.0 到1.1。 然后到今天的2.0，许多优化过的，新的特性被加入，恕鄙人还没完全看完所有的文档，不便多讲。