开发专家谈Web框架

我认为目前在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对象的文档中根本没有提到这个问题！有趣的是，传统上不重视文档的微软公司对于这个问题的讨论却比任何其它公司都好。