带有纯 Javascript 视图的 PHP MVC：好的做法？答案

【问题标题】：PHP MVC with pure Javascript View : good practice?带有纯 Javascript 视图的 PHP MVC：好的做法？
【发布时间】：2011-07-20 21:49:13
【问题描述】：

我的问题可能不够理解，所以让我解释一下情况：

我正在开发一个使用 CodeIgniter 的 PHP 构建的大型 ajax webApp 服务器端。这个框架清楚地划分了模型、控制器和视图。视图文件以 HTML 格式呈现，然后发送到对其进行一些 js 处理（如附加事件）的客户端。

这种工作方式对我来说似乎很奇怪，因为它将服务器端和客户端之间的视图分开。

我正在考虑将所有视图处理移动到客户端部分，该部分将在 js 中动态构建其 html。然后服务器端将只发送原始数据。

我在较小的项目中以这种方式工作，我对结果非常满意（易于理解、便携和可重复使用）。

这是实现 MVC 应用程序的正确方法吗？关于这种反思的任何建议？

【问题讨论】：

只是一个技巧：每当 ajax 变得更流行时，网站管理员现在必须做 2 次网站！（哦！）
O'Reilly 有一本名为 JavaScript Web Applications 的书……它间接地支持你……它展示了更多的功能是如何向客户端移动的……我也撰写了关于客户端的观点，最近也将我的会话管理移到了客户端。

标签： php javascript oop model-view-controller codeigniter

【解决方案1】：

在一个相当大的数据服务应用程序上，我已经完成了您所描述的作为内部应用程序的大部分工作。在我的例子中，我使用 ExtJS 进行客户端渲染/视图，并与 Web 服务器上公开的 C# WCF 端点进行通信。本质上，请求是发出/提交的，响应是序列化到 JSON 的。一旦解决了一些问题，它就运行得非常顺利。原作者编写了一个自定义序列化程序来直接从他们的数据层直接生成结果......这会导致大量额外的数据流向管道。只要您对有效载荷数据谨慎，它就会非常有效。

不过有一些注意事项...

如果您希望未启用 javascript 的用户能够访问该网站（任何涉及来自外部用户的金钱交易），您可能应该避免这种情况。
您需要尽可能清楚地记录您的方法。
在您实现应用程序后为维护任务寻找开发人员将非常困难。（许多服务器端开发人员对 JS 技能感到害羞、害怕，或者只是无能为力。

在大多数情况下，这是一个折腾，我发现大多数人至少启用了 JS，但可能会阻止其他事情。目前 AJAX/XmlHttpRequest 支持几乎是通用的。

关于客户端显示的模板，有几个选项（但这是一个单独的讨论）。

【讨论】：

【解决方案2】：

在 MVC 模式中构建 JavaScript 视图可以正常工作，因为您的视图不会与您的业务逻辑或模型混在一起。

但是，使用完整的 javascript 视图有几个缺点。如果客户端关闭了javascript，它主要消除了优雅降级的能力。此外，某些浏览器 (IE) 没有非常快的 javascript 引擎，这会使您的页面加载更慢。确实，有些视图在客户端和服务器之间是分开的，但仔细想想还是有道理的。

在大多数情况下，您发送给客户端的 HTML 对每个人都是相同的（除非您在服务器端进行浏览器检测）。然而，JavaScript 例程是不同的。如果您使用 JQuery 之类的库，这将对您隐藏，但在每个客户端上运行的代码可能会有很大差异。其中一个例子是 Firefox/webkit 等浏览器使用的 XMLHttpRequest 和 IE 使用的活动 x 控件。由于内容的 html 部分对每个人都是相同的，因此在服务器上构建是有意义的，并且由于视图的 JavaScript 部分可能不同，所以它是在客户端构建的。

HTH

【讨论】：

【解决方案3】：

我开始使用相同的方法：用户界面层使用 JavaScript，数据库访问层使用 PHP。我正在使用 AJAX 在 2 层之间来回传递所有数据。到目前为止，AJAX 偶尔会冻结在我身上，但大多数时候它已经足够快了。所以我想它会很好用。

（结果是我的代码已经从 90% 的 PHP 和 10% 的 JavaScript...变成了 65% 的 JavaScript 和 35% 的 PHP。）

我还将页面视图的代码与触发事件操作函数的代码分开。所以我喜欢认为我现在有一个 MVC 安排（即使我没有使用像 Backbone.js 这样的现成 MVC 框架）。

不过，我没有使用 HTML 模板。我认为 HTML 和编程之间 100% 分离并不自然。我认为简单的编程循环、条件语句和 JavaScript 触发器都与 HTML 相得益彰。

【讨论】：

【解决方案4】：

如果您认为它的方式是创建 html/js 引擎的主视图和带有数据流的几个 ajax 视图 - 在 MVC 术语 imo 中这将是相当不错的。

【讨论】：

【解决方案5】：

网站本身有什么更动态的事情吗？它会做更多的 AJAXy 事情，动态刷新网站的某些部分等吗？如果是这样，拥有一个纯 Javascript 的网站可能是合理的。

由于这不是 Web 传统的工作方式，因此从服务器发送 HTML 仍然是基线。如果您的页面基本上是静态的，如果您想为老客户、可能禁用 Javascript 的受众、可能对纯 Javascript 页面存在可访问性问题的受众、无法理解 Javascript 或搜索引擎的替代客户端提供服务，则您应该提供 HTML来自服务器的页面。它没有任何问题，它直截了当，简单且万无一失。在客户端用 Javascript 重新发明轮子时，需要考虑很多事情。除非您很好地利用了此提供的潜力（例如，请参阅高度动态的 Facebook 或 Twitter 页面），否则它可能对您的用户来说更麻烦。

【讨论】：

实际上所有服务器请求都是 ajax 请求，这就是为什么以这种方式工作对我来说很有意义。 2011 年我们还需要考虑非 js 浏览器吗？

【解决方案6】：

听起来您离从 MVC 模式到 MVVM 模式只有一步之遥。

MVVM 非常适合复杂的用户界面（这正是您将使用所有 AJAX 和 JavaScript 等创建的界面），因为在这种情况下，您的 HTML 视图将能够通过 JavaScript 充当控制器。有一个名为 Knockout JS 的库（警告：我从未使用过，但看起来很有希望）。

【讨论】：

有趣，我不知道那种模式。我去看看，谢谢！