《Struts2技术内幕》自评 —— 尚未完成的话题
程序员文章站
2022-05-17 23:11:36
...
此文接我另外一篇博客：新书上市：《Struts2技术内幕》
虽然我的《Struts2技术内幕》洋洋洒洒写了快400页，不过回过头来看，废话和败笔所占的篇幅应该不到1/3，总算对读者有一番交代。从另一个角度说，有关Struts2和Web开发这个话题，值得讨论的地方还很多。
在书的第二章中，我列出了6个Web开发中的主要问题：
1. 当浏览器发送一个Http请求，Web容器是如何接收这个请求并指定相应的Java类来执行业务逻辑并返回处理结果的？
2. Web应用是典型的“请求-响应”模式的应用，数据是如何顺利流转于浏览器和Java世界之间的？面对Http协议与Java世界数据形式的不匹配性，我们如何在流转时能够做到数据类型的自动转化？
3. Web容器是一个典型的多线程环境，针对每个Http请求，Web容器的线程池会分配一个特定的线程进行处理。那么如何保证在多线程环境下，处理请求的Java类是线程安全的对象？如何保证数据的流转和访问都是线程安全的？
4. Controller层作为MVC的核心控制器，如何能够在最大程度上支持功能点上的扩展？
5. View层的表现形式总是多种多样的，随着Web开发技术的不断发展，MVC如何在框架级别提供一种完全透明的方式来应对不同的视图表现形式？
6. MVC模式虽然很直观地为我们规定了表示层的各种元素，但是如何通过某种机制把将这些元素有机整合在一起，从而成为一个整体呢？
这6个问题的概括，对于Web开发的思考角度是完全不同的。在后来的章节中，其中的部分问题，我已经结合Struts2给出了一个解决方案；而其中的部分问题，我却没有详细展开。算是书中的另外一个遗憾。
造成这一遗憾的原因很多。我在整本书完成以后，也从整体的角度考虑了这一问题，大概归纳了有这么几条：
1. Struts2作为一个表示层的框架，它对于表示层所提出的解决方案受到历史传统的深刻影响，因而它无法在某些问题上形成突破。
这一点，在Struts2始终秉承着以XML为核心配置元素上显得尤为突出。在JDK1.5广泛流行之后，Struts2似乎也不愿意在XML和Annotation之间的大战中做出任何让步。
2. Struts2所提出的编程模型比较独树一帜，导致了它与其他MVC框架之间的发展道路和发展轨迹也完全不同。
正因为发展道路和发展轨迹完全不同，所以一旦底层的XWork模型不发生质的改变，Struts2的发展也不会非常活跃。而发展轨迹的不同，也导致其发展始终无法和其他的MVC框架形成正面竞争。因为既然基础都不一样，比较起来有时候就失去了意义。
3. 由于书的主题比较鲜明，所以无法从更广的角度来谈很多问题。
没有一个解决方案是绝对完美的，Struts2也不例外。不过由于书本身有一个主题，所以任何话题都不能过于偏离书的本身。这就导致了我在评论某些设计理念时，不能将某些话题延续得更深。
所以，我也在考虑规划我的下一本书的内容。选取另外一个MVC框架中的翘楚SpringMVC作为主题，并且将Struts2和SpringMVC做一个深度的比较，探寻Web开发的最佳实践。
我将在接下来的时间陆续在博客上发布一系列有关SpringMVC的文章，敬请期待。
虽然我的《Struts2技术内幕》洋洋洒洒写了快400页，不过回过头来看，废话和败笔所占的篇幅应该不到1/3，总算对读者有一番交代。从另一个角度说，有关Struts2和Web开发这个话题，值得讨论的地方还很多。
在书的第二章中，我列出了6个Web开发中的主要问题：
1. 当浏览器发送一个Http请求，Web容器是如何接收这个请求并指定相应的Java类来执行业务逻辑并返回处理结果的？
2. Web应用是典型的“请求-响应”模式的应用，数据是如何顺利流转于浏览器和Java世界之间的？面对Http协议与Java世界数据形式的不匹配性，我们如何在流转时能够做到数据类型的自动转化？
3. Web容器是一个典型的多线程环境，针对每个Http请求，Web容器的线程池会分配一个特定的线程进行处理。那么如何保证在多线程环境下，处理请求的Java类是线程安全的对象？如何保证数据的流转和访问都是线程安全的？
4. Controller层作为MVC的核心控制器，如何能够在最大程度上支持功能点上的扩展？
5. View层的表现形式总是多种多样的，随着Web开发技术的不断发展，MVC如何在框架级别提供一种完全透明的方式来应对不同的视图表现形式？
6. MVC模式虽然很直观地为我们规定了表示层的各种元素，但是如何通过某种机制把将这些元素有机整合在一起，从而成为一个整体呢？
这6个问题的概括，对于Web开发的思考角度是完全不同的。在后来的章节中，其中的部分问题，我已经结合Struts2给出了一个解决方案；而其中的部分问题，我却没有详细展开。算是书中的另外一个遗憾。
造成这一遗憾的原因很多。我在整本书完成以后，也从整体的角度考虑了这一问题，大概归纳了有这么几条：
1. Struts2作为一个表示层的框架，它对于表示层所提出的解决方案受到历史传统的深刻影响，因而它无法在某些问题上形成突破。
这一点，在Struts2始终秉承着以XML为核心配置元素上显得尤为突出。在JDK1.5广泛流行之后，Struts2似乎也不愿意在XML和Annotation之间的大战中做出任何让步。
2. Struts2所提出的编程模型比较独树一帜，导致了它与其他MVC框架之间的发展道路和发展轨迹也完全不同。
正因为发展道路和发展轨迹完全不同，所以一旦底层的XWork模型不发生质的改变，Struts2的发展也不会非常活跃。而发展轨迹的不同，也导致其发展始终无法和其他的MVC框架形成正面竞争。因为既然基础都不一样，比较起来有时候就失去了意义。
3. 由于书的主题比较鲜明，所以无法从更广的角度来谈很多问题。
没有一个解决方案是绝对完美的，Struts2也不例外。不过由于书本身有一个主题，所以任何话题都不能过于偏离书的本身。这就导致了我在评论某些设计理念时，不能将某些话题延续得更深。
所以，我也在考虑规划我的下一本书的内容。选取另外一个MVC框架中的翘楚SpringMVC作为主题，并且将Struts2和SpringMVC做一个深度的比较，探寻Web开发的最佳实践。
我将在接下来的时间陆续在博客上发布一系列有关SpringMVC的文章，敬请期待。