logo标签列表

使用纯Javascript视图的PHP MVC：是一种好的实践吗？

phpjavascriptoopmodel-view-controllercodeigniter
4
我的问题可能不太容易理解，让我解释一下情况：
我正在开发一个大型的ajax webApp，使用PHP和CodeIgniter框架在服务器端构建。该框架明确区分模型、控制器和视图。视图文件以HTML形式呈现，然后发送到客户端进行一些js处理（例如附加事件）。
这种工作方式对我来说似乎有些奇怪，因为它将视图分开放置在服务器端和客户端。
我正在考虑将所有视图处理移动到客户端部分，在js中动态构建其html。然后，服务器端将仅发送原始数据。
我在较小的项目中采用了这种方式，并且非常满意结果（易于理解、可移植和可重用）。
这是实现MVC应用程序的正确方法吗？对于这种思考，有什么建议吗？
只是一个想法：随着Ajax变得越来越流行，现在的网站管理员不得不做两次网站！（哎！） - dynamic
O'Reilly出版了一本名为JavaScript Web应用的书，该书在间接支持您的同时展示了更多的功能正在向客户端转移。我也在客户端上组织我的视图，并最近将我的会话管理也迁移到了客户端。 - user656925
6个回答
3
我曾在一款数据服务应用上完成了与您所描述的类似的工作，该应用是一个内部应用。在我的情况下，我使用了ExtJS进行客户端渲染/视图，并通过Web服务器上公开的C# WCF端点进行通信。基本上，请求被发出/提交，响应被序列化为/从JSON中读取。一旦解决了一些问题，它就运行得非常顺畅。原始作者编写了一个自定义序列化程序，以直接从他们的数据层获取结果...这会导致许多额外的数据传输。只要您对有效负载数据保持谨慎，它就可以非常有效。
但需要注意以下几点：
- 如果您希望未启用JavaScript的用户能够访问站点（包括外部用户的货币交易），则应该避免这种方法。 - 您需要尽可能清楚地记录您的方法论。 - 在实现应用程序后找到维护任务的开发人员将非常困难（许多服务器端开发人员不熟悉JavaScript技能）。
总体而言，这是一个很棘手的问题，我发现大多数人至少已经启用了JS，但可能会阻止其他事情。 AJAX / XmlHttpRequest支持目前几乎是普遍的。
至于客户端显示的模板，有几个选项（但这是另一个讨论）。
2
我开始采用同样的方法：JavaScript作为用户界面层，PHP作为数据库访问层。我使用AJAX在这两个层之间传递所有数据。到目前为止，AJAX偶尔会卡顿，但大部分时间速度都很快。所以我想它足够好了。
结果是，我的代码从90% PHP和10% JavaScript变成了65% JavaScript和35% PHP。
我还将页面视图的代码与触发事件操作函数的代码分开。所以我认为现在我有了一个MVC结构（尽管我没有使用像Backbone.js这样的现成MVC框架）。
不过我没有使用HTML模板。我认为在HTML和编程之间完全分离并不自然。我认为简单的编程循环、条件语句和JavaScript触发器都与HTML很好地配合。
2

在MVC模式下，使用JavaScript视图可以很好地工作，因为您的视图不会与业务逻辑或模型混合在一起。

然而，完全使用JavaScript视图存在几个缺点。主要包括：如果客户端关闭了JavaScript，则无法优雅降级；有些浏览器（如IE）没有很快的JavaScript引擎，这会使页面加载更慢。虽然某些视图在客户端和服务器之间分隔开来，但仍然存在这些缺点。

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

希望对你有所帮助。

0

如果你从这样的角度来思考，即有一个主视图创建了HTML/JS引擎和几个带有数据流的Ajax视图，那么在MVC术语中，它会相当不错。

0

网站本身还有更多动态的内容吗？ 它是否会进行更多的AJAX操作，动态刷新网站的某些部分等？ 如果是这样，那么仅使用Javascript的网站可能是合理的。

尽管如此，由服务器发送HTML仍然是基准，因为这不是Web传统工作的方式。 如果您的页面基本上是静态的，如果您想为旧客户端提供服务，针对禁用Javascript的受众，针对仅能了解Javascript或搜索引擎的替代客户端，以及存在Javascript-only页面可访问性问题的观众，您应该从服务器提供HTML页面。 这没有任何问题，非常直接、简单和可靠。 当在客户端重复发明轮子时，需要考虑许多因素。 除非您可以很好地利用其提供的潜力（例如高度动态的Facebook或Twitter页面），否则它可能会给您的用户带来更多麻烦而不值得。

实际上，所有服务器请求都是ajax请求，这就是为什么按照这种方式工作对我有意义的原因。在2011年，我们是否仍然需要考虑非JS浏览器？ - MisterCashew
0

听起来你离从MVC模式转换到MVVM模式只有一步之遥了。

MVVM非常适合复杂的用户界面（这正是你将通过所有的AJAX和JavaScript等创建的内容），因为在这种情况下，你的HTML视图将能够通过JavaScript充当控制器。有一个库（警告：我从未使用过，但它看起来很有前途）可以实现这一点，叫做Knockout JS。

有趣，我不知道那个模式。我会看一下，谢谢！ - MisterCashew
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接