我认为目前在Web应用的需要与框架所提供的支持之间存在严重的脱节。诚然，无可否认的是，与CGI时代相比，我们已经取得了很大的进步，但是我们仍有很长的路要走。

我还不想说我们需要一种新的Web开发语言，但我确实认为与其说是编程困难不如说是程序设计语言的问题。

而且我的确认为当前的框架对于编写像客户端/服务器应用、主机应用、或简单的无连接桌面应用等拥有所有相同功能的实际应用的开发人员，已经不能满足他们的需要。

为了便于介绍，我们主要集中于主流的框架（J2EE、ASP.NET和PHP），我也很想在本文中包含Ruby on Rails，可能一些读者会提供帮助，但我对该领域的了解不足以胜任写有关的技术性文章，而且很明确它也不是“主流”框架。

框架内共享对象内的线程安全

第一点需要指出的是Web代码的自动并行化。无论大多Web开发人员是否注意到这一点，但他们的代码总有同时执行的风险，即使在个人用户的水平。换句话说，假设如果你要编写一个桌面应用，而且每个按钮单击，拖/放行为等立即在一个独立的线程中执行事件处理。

这肯定会改变处理如数据一致性，类内私有变量的访问等问题的方式，不是吗？这就是在编写基于Web应用时需要面对的问题。我并不是说Web服务器或Web框架应该将所有请求串行化（虽然如果将串行化做成一个可配置的选型会更好，尤其是在用户会话级）。

目前的Web框架往往以不同的方式处理这类问题，但是很少有优化或配置的方式。例如，微软的ASP.NET文档中有关于会话状态和并发问题的部分介绍。

访问ASP.NET的会话状态是独占的，这意味着如果两个不同的用户并发请求，可以并发地许可访问每个独立的会话。不过，如果对同样的会话发出并发请求（即使用同样的会话ID值），那么接受的第一个请求将会独占访问会话信息，一旦第一个请求完成或对信息的排他所由于超时释放，那么第二个请求将会执行。

如果EnableSessionState页面指示被设为只读，那么对只读会话信息的请求不会导致对会话数据添加排他锁。对会话数据的只读访问请求可能会等待对会话数据读写请求所获得的锁的清除。

换句话说，会话数据被锁定，但在调用级别上它必须是一个排他锁。ASP.NET中的会话对象不支持为整个页面代码或部分代码上锁的模式或方法。为了保证数据安全，开放人员必须采取措施如将调用会话对象的任何代码包装到一个关键段中等。

PHP采取完全不同的方针。尽管它的文档中通常不会提到数据并发的挑战（当我说到这一点时，我的意思是PHP文档是很令人讨厌的），但是一个友好的访问者对这个问题提出了一些有用的信息（可以看文档中的评论）。

如果一个用户是正确的，那么会话的使用将会锁定会话对象的调用，它可以强制地串行处理页面。虽然不是最佳的，但至少可以保证安全。根据上面的介绍，开发人员被强制跳过一些步骤去做其它事情。

最后，J2EE关于HttpSession对象的文档中根本没有提到这个问题！有趣的是，传统上不重视文档的微软公司对于这个问题的讨论却比任何其它公司都好。

页面模型

总的说来，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应用取代桌面应用的话，那么要想较好的实现需要给开发人员提供一些工具。而且，我认为目前任何一个主流框架都不能满足我们的需要。

来源： http://blogs.techrepublic.com.com/programming-and-development/?p=427