使用jQuery standalonne与服务器端表示框架的Web应用程序

Question

我开始将演示交易应用程序的前端重写为富Web客户端（当前实现在Silverlight中 - 您可以看到它here）。我正在考虑重写两个选项：

1. 独立的基于JavaScript客户端使用框架如jQuery UI
使用客户端框架如jQuery UI加一个服务器端框架，如
2. 混合型客户端ASP.NET MVC3，JSF，GWT等。

您对每种方法的优缺点有何看法？我主要在寻找能够应用良好的架构原则（如MVC和事件）来创建易于理解和维护的干净模块化设计。

编辑：看看回复，我想澄清一下，存在执行大量业务逻辑的服务器组件（请参阅此architecture diagram）。客户端只需使用基于JSON的服务将其命令和查询发送到服务器。在这方面，客户真的很轻，只专注于用户交互和呈现。

那么我真的后：

a）关于使用什么框架，接近1和2，实现了为什么一个方法是有效好过清洁模块化设计

B）意见指导其他

例如，我会倾向于＃1，前提是JavaScript框架的组合足以轻松创建健壮的表示层。换句话说，如果我要投资一个JavaScript重型客户端，为什么在服务器端框架中引入额外的依赖关系 - 这是否真的让我的工作更容易？ （假设有任何一种学习曲线）

Answer 1

GWT是客户端。它可以替代jQuery，如果你使用它与gwtQuery。

技术的选择实际上取决于许多因素（您在此未提及），但主要依赖于您已知的内容。我个人喜欢：

1. GWT和gwtQuery客户端，主要是因为我知道他们。客户端将是pure-ajax，所有业务逻辑都在服务器上完成。

2. REST服务器，执行业务逻辑并向客户端提供（呈现）数据。有很多REST技术，我个人知道Resteasy，所以我会使用它。

更新：

在1与2的方法：方法1，主要用于复杂的Web应用程序（也称为Gmail中），其中网页是不是重新加载，所有的交互是通过做DOM操作和AJAX调用。它给你更好的响应能力（页面不重载）和更好的加载时间（因为几乎没有HTML传输，只有JSON数据）。如果你想拥有丰富的用户界面体验，无论如何你都需要在客户端使用一些JS，所以你永远不会完全摆脱这一部分。

缺点是你需要知道JS。当代码库增长时，JS代码也会有可维护性问题。不过，如果你使用GWT，所有这些都可以减轻：java是静态类型的，编译成最小尺寸的JS，并且抽象浏览器的怪癖（提供抽象的DOM访问）。另外它还有很棒的IDE支持（Eclipse和IDEA），GUI builder（如果你需要的话），模块化（MVP），很棒的文档，吨库和我最喜欢的gwtQuery（jQuery的一个克隆）。

所以，我个人的选择仍然是方法1.以GWT作为技术主要是因为我已经知道这项技术。

Answer 2

这取决于需要完成多少计算。由于这是一个承诺执行0秒的交易应用程序，因此您无法真正依赖于客户端浏览器在没有挂起或冻结的情况下执行所有脚本。当然，这不是唯一的问题，因为混合解决方案也可能会发生这种情况，但是执行客户端代码的代码要少得多，这可以让您关注所需的资源。

关于维护的话题：客户端执行的JS可能不像MVC应用程序那样容易维护。保持代码的可读性和可维护性仅仅是个人或团队纪律的问题。

如果建筑的原则是你的决定是一个大问题，我会去每一次的混合解决方案。由于更新问题

更新：

在已经处理的逻辑，在客户端只需要做更新和DOM操作的情况下，我可能会根据情况决定在服务器端架构或个人喜好。这取决于长期目标。如果你想坚持一个架构，你可以使用ASP.NET，它提供了各种支持AJAX的控件/对象。

个人而言，我会使用jQuery的AJAX功能，仅仅是因为我知道它的工作原理，到目前为止完美的我JSON对象（在我们的内联网，我们正在使用它的ASP。NET后端），因为jQuery在客户端上非常轻量级。缩小版本在字节中的权重并不重要，并且已针对性能和跨浏览器不兼容性进行了优化。使用asp，您仍然必须自己寻找跨浏览器的交易断路器，而不是专注于手头的任务，客户端本身