开发专家谈Web框架

页面模型

总的说来，Web应用中“页面”的概念是有意义的，尤其是由于历史原因。不幸的是，对编写应用来说页面模型是相当无用的。当使用一个应用时，用户不会调用“页面”，他们单击按钮、拖动项目等等。换句话说，他们执行数据操纵。

AJAX诞生于将一个“应用”作为事件驱动模型的需要，在该模型中每个用户行为触发一段离散代码。按照现实情况尽管我认为AJAX并不是一个好主意（JavaScript问题、异常处理问题、调试困难、太多的HTTP请求等），但是至少它包含正确的想法。

不使用AJAX的话，几乎不可能使一个Web “应用”像一个应用那样使用尽管仍旧使用了HTML。让我们面对现实，HTML设计用来表达只读的操作，对数据操纵只有很少的支持。

这就是使用页面模型的问题所在。ASP.NET控制部分页面的软件组件“Web Parts”和J2EE的“Faces”等技术是个良好的开端，可以使得“页面”像个容器一样可以包含一些小的功能块。这肯定更接近从前的桌面开发时的组件编写与重用。虽然当前的框架正在解决这个问题，但是页面模型走向像Eclipse和Visual Studio等集成开发环境定义“应用”的方式还需要很长的路要走。

他们仍旧在调整已经被证实不能很好地用于应用开发的页面模型。PHP的来源是如此接近CGI，所以也缺少这类的工具。一个PHP开发人员要想做同样的事情，要在他们的代码中添加大量的包含文件，就代码而言，这造成了很大的混乱。

客户/服务器交互

目前的技术发展水平是把数据和部分客户端代码抛过HTTP服务器的防护，然后看看返回的内容。尽管从技术上来说，这是准确的并且后面有历史优先的推动，但对应用开发人员来说这是一个反直觉问题。比如说，无缝的调试客户端代码和它与服务器端代码的交换是很困难的。

我对Eclipse的应用比较少，不足以判断或接触Visual Studio这个“魔兽”，但我知道我需要一个工具来在JavaScript脚本中设定断点，单步跟踪代码以及从对服务器数据请求的开始登陆。目前的框架还没有制度化客户端代码或还没开始将它走为一个对等的部分。在桌面应用中，很容易发现那个用户行为触发了要处理的事件。

在一个Web应用中，这是不可能的。一个搜索引擎以一个表单为目的地与一个用户以它为目的地没有什么区别。这既可能给用户带来问题，也可能导致安全风险。我们很难找到这样的应用用户可以任意触发可视化窗口可以访问的方法和函数（当然，没有一些高级的开发人员工具和包含调试符号的生成器），然而这正是一个Web应用的真实特性。编码时如何不细心，“恶意用户”可以简单的混乱一个应用。这就是目前Web开发框架实现客户/服务器交互的方法所导致的直接后果。

结论

实际上这不是一个关于“桌面应用”对“Web应用”的问题，但从某个方面来说，也确实是这方面的问题。用户和产品经理们期望越来越多的Web应用。毕竟，我们（或者说我们中的大部分人）有用Web应用取代客户/服务器应用和主机应用的想法。问题是Web应用试图取代的应用拥有的无缝开发模型已经使用了很长时间。

Web应用中函数的功能仍旧处于桌面应用世界1990年以前的水平（不说1985年的话）。如果用Web应用取代桌面应用的话，那么要想较好的实现需要给开发人员提供一些工具。而且，我认为目前任何一个主流框架都不能满足我们的需要。

责任编辑：德东

查看本文国际来源