Web构架理论化初探

大约两年前，在研究petStore WAF时写了个东西，感觉上有点理论化的趋势，所以一直不敢发到网上来 。现在想就当抛砖引玉，起个和大家交流的机会吧 。修改了一下，就斗胆把它发上来了，请大家多多指教...

把文章帖出来贝，打在rar中，看起来多不方便呀

2. WAF所面临的两个框架性问题
从最初的B/S开发的实际情况开始思考，当用户提交请求时，服务端必须为这个请求找到应答的代码，比如指定的JSP文件（包括出错页面），或者java功能模块。但是这样的请求必定会是多种多样甚至难于统计的，所以，我们的服务器端的程序，必须解决一个问题，那就是请求的路由问题。这就是我们找到的WAF所面临的第一个问题。
其次，当一个请求得到处理之后，WAF将面临第二个问题，那就应答导向的问题。即是说，当请求处理完之后系统返回时的页面选择问题。如何决定请示处理完成之后，出现哪一个页面？
概括地说是让请求到达目的地，并从目的地顺利返回。

3. 解决问题的抽象框架

3.1 请求与功能模块之间的对应关系
在系统开发需求确定了之后，系统的业务目标显然已经成为已知(一定时期内可以确定)的了，即是说，我们甚至可以在系统开发编码的前期就能把系统的后台逻辑功能模块写出来。比如操作数据库的增加、删除、修改、查寻功能等等。这些功能模块正是服务于用户请求的。但是我们如何让这些功能为特定的用户请求服务呢？
当用户提交请求时，我们会发现，用户提交请求时的地址路径是区别用户请求的重要标志。虽然，在同一个地址请求下还会有诸如增加，删除之类的更细的动作请求。但我们可能把地址请求作为请求的大类，而动作请求作为地址请求中的一个小类。这样我们必然会有这样一种解决问题之后的状况，那就是，地址请求与业务模块(一个相对小的用例)之间存在对应关系，动作请求与业务方法之间存在对应关系。

3.2 请求表单与业务输入的对应关系
用户请求必然伴随着表单的提交，这样表单内容，就是用户请求所输入的请求条件。我们在提供业务功能时，也同样作了条件输入的假设，比如要求提供删除记录的ID号，增加记录的记录集或对象等等。我们可以清楚地看到，业务功能所假设的输入条件，正是用户请求表单所要提供的，或者说这些假设条件都包含在用户所提交的表单中。
这样，我们可以看到用户表单和业务输入之间存在着对应关系。

3.3 业务功能与应答结果的对应关系
业务处理完成之后，必然会有一个结果，或者影响，系统大部分时候需要把这样一个结果和影响展现给用户。这就是说业务处理本身就决定了应答结果。我们只需要在业务处理结束之后，返回这样一个应答结果就可以了。在实际系统中，这种情况或反映为返回一个页面的链接。

3.4 对应关系的建立
我们知道我们面临的问题或者说是WAF所面临的问题是请求的路由问题和应答的导向问题。但是我们找到了三种关系，那就是请求地址与功能模块之间的对应关系、请求表单与业务输入的对应关系和业务功能与应答结果的对应关系，这三个关系正是为我们解决请求路由问题提供了路径。所以，我们只要建立这三种关系就相当于解决了构架所面临的问题，因为请求最终得于路由到了指定的业务模块以及业务处理完成之后得以返回。[/b]

主要是还想继续写，结合webwork,tapestry,spring所代表三种比较典型的思想，抽象概括出来，看看它们到底为我们解决了什么问题？问题是怎么解决的？它们的思想和出发点是什么？等等。

对大师们的实践上升到理论的高度来理解。

支持楼主这种积极上进的理想.

写吧,多写些这样的东西,别忘了第一时间贴在这里!
另:对你提出的3.1,3.2的struts解决方案我有写自己的看法,连接如下
http://www.iteye.com/viewtopic.php?t=14714