网络框架 API

Posted 2023-02-22

【中文标题】网络框架 API

【英文标题】：Web framework API

【发布时间】：2010-11-11 18:24:59

【问题描述】：

我不是 Web 开发人员，我对那里的 Web 应用程序框架了解不多。

然而，最近，我进入了Wt。这是一个用 C++ 编写的 Web 框架（这就是我进入它的原因），但最让我印象深刻的是它所基于的想法。

它的 API 不同于我听说过的任何 Web 框架（CppCMS、Yii、Django、Pylons、Zope、Drupals、Java Servlets、Struts ...）：为任何用户会话创建一个新的应用程序对象，并且它在会话到期之前一直保持活动状态（仅在此时 Application 对象被销毁）。这个 Application 对象像桌面窗口一样工作：您将小部件放入其中（窗体、链接、标签等小部件......）；当用户点击一个链接时（当 HTTP 服务器接收到一个新的 GET/POST 请求时），一个函数被调用到紧贴用户会话的对象上（以一种很好的 Signal/Slot 方式），它可以删除/添加/更改小部件，从而改变用户将看到的页面。

正如我所说，我对 Web 框架不是很熟练，我几乎只开发桌面应用程序；也许出于这个原因，我认为 Wt 背后的这个范式很棒。

我想知道这个框架 API 相对于其他 API 的优缺点是什么，以及是否还有其他基于相同概念的框架（也包括其他语言）。

【参考方案1】：

Wt 对于其预期的应用范围来说是一个很棒的框架。

Wt 非常适合：

Web 应用程序与会话紧密耦合，即 仅供登录用户访问（登录页面除外） 显示大量与用户相关的内容（因此不适用于 wiki） 严重依赖状态 需要大量控件/按钮和用户输入的网络应用程序。

例如，我打算写一个浏览器MMORPG。页面都将具有与用户相关的状态，并且会有很多按钮。 Wt 非常适合。我曾经是一名 Ruby on Rails 开发人员，为这种应用程序切换到 Wt 是一个很棒的时刻。使用试图强制执行纯 REST 的传统框架来设计表单非常麻烦。

Wt 也非常适合某些进程的控制界面。例如，允许您的客户配置他们的广告活动等的界面。

当然，使用 Wt 在控制和分离方面并不完美，但是当您只需要“经典”功能（按钮、编辑器等）时，它可以非常快速开发

因此，根据经验，如果您尝试将桌面应用程序放到网络上（这是一个好主意，无需在客户的机器上进行部署和更新），Wt 是一个不错的选择。

此外，如果您与现有的 C++ 代码库交互，Wt 具有优势。

【参考方案2】：

我认为这通常是个坏主意。

Web 应用程序与 GUI 应用程序非常不同，原因有很多：

99% 的网络是关于内容的，而不是关于迭代的。

您访问网络是为了获取或共享内容，而不是进行一些实时交互 比如画图、使用电子表格或其他任何东西。 Web 是内容驱动的，而不是“事件驱动”的交互式应用程序。

这对您如何创建大部分网络具有重大影响 - 您带来信息 用户而不是与他交互。

服务端和客户端编程很不一样

有一些 Web GUI 应用程序，如电子邮件、聊天客户端，但性能良好 他们需要很好的分离客户端之间的书面 在高质量的 Java Script 和使用的高质量服务器端后端中 通过 AJAX 进行内容检索。

像 Wt 那样隐藏这种分离或（其他已知框架）会导致糟糕 从长远来看，软件通常带来的问题多于解决方案。

因为服务器端和客户端作业之间应该非常明确的分离 因为有些需要实时响应，有些则不需要。

当您尝试一次性解决所有这些问题时，请等待问题。注意，有客户端-服务器 GUI 的解决方案（以 X-Server 为例），但与他们为此设计的 web 不同 而是更像 IPC 而不是客户端-服务器solitions。

网络大部分时间都是无状态的。

或者更准确地说，状态通常保留相当少量的数据。

创建即时会话对象是个好主意，直​​到您需要... 从长远来看，扩大保存状态然后这个模型变得不太好，当然 这不是 Wt 的“强制”模型，而是符合特定概念的一般概念 有些没有。

底线

如果您想设计像 Web 应用程序这样的良好 GUI。开始学习 javascript 并使用适合 GUI 甚至驱动设计的良好 GUI JavaScript 框架。然后将它们与一些服务器端 API 结合使用一些交互 RPC 模型，如 Json-RPC、XML-RPC 等 AJAX 工具。

这是为高度交互的应用程序做正确事情的方法。

如果您的应用程序更面向内容，那么大多数服务器端 Web 框架做得很好 - 专注于服务器端，其出色的工具适合 为了这份工作。

一站式解决方案？它只是不起作用......

披露：我是 CppCMS 的开发者，我认为 Wt 只是走错了路。

【讨论】：

虽然您的一些论点是正确的，但您缺乏从不同类型的应用程序的视角。看我的回答。

我认为您将 Wt 描述为“通常是个坏主意”是不公平的。它非常适合某些类型的网络应用程序。

【参考方案3】：

ASP.NET 类似；它的目标是让 Web 开发看起来像桌面应用程序开发。

【讨论】：

我不是反对者，但 Asp.Net 方法与 Wt 的方法非常不同，而且众所周知，当它按原样使用时会表现得很糟糕。这不是 Asp.Net 的强项:-)