Web框架API

Question

我不是一个Web开发人员，我对web应用程序框架也不太了解。

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

它的API不同于我所听说过的任何web框架(CppCMS、Yii、Django、Pylons、Zope、Drupals、Java、Struts .)：为任何用户会话创建一个新的应用程序对象，并且在会话到期之前它一直处于活动状态(仅在此时应用程序对象被破坏)。这个Application对象的工作方式类似于桌面窗口:您将小部件放入其中(小部件如窗体、链接、标签.)；当用户单击链接(当HTTP服务器收到新的GET/POST请求时)，会在对象上调用函数(以良好的信号/插槽方式)，该函数可以删除/添加/更改小部件，从而更改用户将看到的页面。

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

我想知道这个框架API相对于其他框架的利弊是什么，以及是否有基于相同概念的其他框架(也是其他语言)。

Answer 1

Wt是的一个很好的框架，它预定的应用程序范围为。

Wt非常适合：

• 与会话紧密耦合的网络应用程序，即
  • 仅供登录用户访问(登陆页除外)
  • 显示大量与用户相关的内容(而不是wiki)。
  • 严重依赖国家

​

• 需要大量控件/按钮和用户输入的web应用程序。

例如，我计划编写一个浏览器MMORPG。页面都会有一个与用户绑定的状态，并且会有很多按钮。Wt是的完美选择。我曾经是Rails的开发人员，而切换到Wt来开发这类应用是一个伟大的时刻。用传统的框架设计表单越来越麻烦，这些框架试图执行纯REST。

对于某些进程上的控制接口，Wt也是完美的。例如，允许您的客户配置他们的adword campain的接口，等等。

当然，在控制和分离方面，使用Wt并不完美，但是当您只需要“经典”功能(按钮、编辑器等)时，它允许极快地进行开发。

因此，根据经验，如果您试图将桌面应用程序放到web上(这是一个很好的主意，无需在客户的计算机上部署和更新)，Wt是一个很好的选择。

另外，如果您正在与现有的C++代码库进行接口，Wt具有优势。

Answer 2

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

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

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

你去网络获取或分享内容，而不是做一些实时互动，如绘制图片，使用电子表格或其他任何东西。Web是内容驱动的，而不是“事件驱动的”交互式应用程序。

这对你如何创建大部分网络产生了强烈的影响--你给用户带来了信息，而不是与他互动。

服务器和客户端编程是非常不同的。

有一些web GUI应用程序，如电子邮件、聊天客户端，但是要执行得好，它们需要在用高质量Java脚本编写的客户端与通过AJAX进行内容检索的高质量服务器端后端之间进行很好的分离。

像Wt这样或(其他已知的框架)一样，隐藏这种分离会导致糟糕的软件，通常会带来更多的问题，而不是长期的解决方案。

因为应该非常清楚地将服务器端和客户端的作业分离开来，因为有些作业需要实时响应，而有些则不需要实时响应。

当你试图一次解决所有这些问题时，等待问题。注意，有一些用于GUI的客户机-服务器解决方案(参见designed为例)，但是与web不同的是，它们是为此而设计的，它们更像IPC而不是客户机-服务器解决方案。

大多数情况下，网络是无状态的。

或者说，为了更准确起见，这种状态通常保存的数据量很小。

创建即时会话对象是个好主意，直到你需要.从长远来看，扩大储蓄状态，这个模型就不那么好了，当然这不是Wt的“强制”模型，但它是一般的概念，适合一定的概念，有些则不适用。

底线

如果你想设计一个好的GUI，比如web应用程序。开始学习JavaScript，并使用很好的GUI JavaScript框架，这些框架甚至适合GUI驱动的设计。然后使用一些交互RPC模型(如Json、XML和其他AJAX工具)将它们与一些服务器端API结合起来。

这是正确处理高交互性应用程序的方法。

如果您的应用程序更面向内容，那么大多数服务器端web框架都做得很好--将精力集中在服务器端，并提供适合于这项工作的强大工具。

都是一个解决方案吗？只是不行..。

披露:我是CppCMS的开发人员，我认为我们走错了路。

Answer 3

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