PHP MVC 与纯 Javascript 视图：好的做法吗？
我的问题可能不太容易理解，所以让我解释一下情况：
我正在使用 CodeIgniter 使用 PHP 构建服务器端的大型 ajax webApp。该框架清楚地分离了模型、控制器和视图。视图文件以 HTML 形式呈现，然后发送到客户端，客户端对其进行一些 js 处理（例如附加事件）。
这种工作方式对我来说似乎很奇怪，因为它将服务器端和客户端之间的视图分开。
我正在考虑将所有视图处理移动到客户端部分，该部分将在 js 中动态构建其 html。服务器端将仅发送原始数据。
我在较小的项目中以这种方式工作，我对结果非常满意（易于理解、便携和可重用）。
这是实现 MVC 应用程序的正确方法吗？关于这个反射有什么建议吗？
My question might not be understandable enough, so let me explain the situation :
I'm working on a big ajax webApp built, server side, with PHP using CodeIgniter. This framework saperates clearly models, controllers and views. The view files are rendered in HTML and then sent to the client that does some js treatments on it (like attaching events).
This way of working seems strange to me, as it separates the view between the server side and the client side.
I was thinking about moving all the View treatments to the client part that will build dynamically its html in js. The server side will then send only raw data.
I worked this way on smaller projects, and I was really happy with the result (easily understandable, portable and reusable).
Is it a right way to implement an MVC app ? Any advices around that reflexion ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我已经在相当大的数据服务应用程序上完成了您所描述的大部分内容作为内部应用程序。就我而言，我使用 ExtJS 进行客户端渲染/视图，并与 Web 服务器上公开的 C# WCF 端点进行通信。本质上，请求是发出/提交的，响应是序列化到 JSON 或从 JSON 序列化的。一旦解决了一些问题，一切就变得非常顺利。原作者编写了一个自定义序列化器来直接从数据层获取直接结果......这会导致大量额外的数据进入管道。只要您明智地对待您的有效负载数据，它就会非常有效。
但有一些警告...
在大多数情况下，这是一个折腾，我发现大多数人至少启用了 JS，但可能会屏蔽其他东西。AJAX /XmlHttpRequest 支持在这一点上几乎是通用的。
至于客户端显示的模板，有一些选项（但这是一个单独的讨论）。
I've done pretty much what you are describing on a fairly large data services app as an internal application. In my case I was using ExtJS for the client-side rendering/views, and was communicating to a C# WCF endpoint exposed on the web server. Essentially requests were made/submitted and responses were serialized to/from JSON. It ran very smooth, once some kinks were worked out. The original author had written a custom serializer to do direct results from their data layer directly... this leads to a lot of extra data going down the pipe. As long as you are judicious with your payload data it can be very effective.
Some caveats though...
For the most part it's a toss up, I find that most people at least have JS enabled, but may have other things blocked off. AJAX/XmlHttpRequest supports is nearly universal at this point.
As to templating for client-side display, there are a few options there (but that's a separate discussion).
构建 JavaScript 视图在 MVC 模式中工作得很好，因为您的视图不会与业务逻辑或模型混合在一起。
然而，使用完整的 javascript 视图有一些缺点。主要是它消除了客户端关闭 JavaScript 时优雅降级的能力。另外，某些浏览器 (IE) 没有非常快的 javascript 引擎，这将使您的页面加载速度更慢。确实，某些视图在客户端和服务器之间是分开的，但是当您仔细考虑时，这是有道理的。
在大多数情况下，您发送到客户端的 HTML 对于每个人来说都是相同的（除非您在服务器端进行浏览器检测）。然而 JavaScript 例程是不同的。如果您使用的是像 JQuery 这样的库，这将对您隐藏，但每个客户端上运行的代码可能会有很大差异。一个例子是 firefox/webkit 等浏览器使用的 XMLHttpRequest 以及 IE 使用的 active x 控件。由于内容的 html 部分对于每个人来说都是相同的，因此在服务器上构建是有意义的，并且由于视图的 JavaScript 部分可能不同，因此在客户端上构建是有意义的。
华泰
Building JavaScript views works fine within the MVC pattern, since your view is not mixed in with your business logic or model.
However, there are a couple drawbacks to using full javascript views. Mainly it eliminates the ability for graceful degradation if the client has javascript turned off. Also, some browsers (IE) don't have a very fast javascript engine, which will make your page load more slowly. It is true that some of the view is separated between the client and the server, but it kind of makes sense when you think about it.
In most cases the HTML that you send to clients is the same for everyone (unless you are doing browser detection on the server side). However the JavaScript routines are different. If you are using a library like JQuery, this will be hidden from you, but the code that is running on each client may differ greatly. One example of this would be the XMLHttpRequest that is used by firefox/webkit etc browser and the active x control that is used by IE. Since the html portion of the content is the same for everyone it makes sense to build on the server, and since the JavaScript portion of the view may differ, it make sense that it is built on the client side.
HTH
我开始使用相同的方法：JavaScript 用于用户界面层，PHP 用于数据库访问层。我使用 AJAX 在两层之间来回传递所有数据。到目前为止，AJAX 偶尔会让我感到困惑，但大多数时候它已经足够快了。所以我想它会运作得很好。
（结果是我的代码从 90% PHP 和 10% JavaScript 变成了 65% JavaScript 和 35% PHP。）
我还将页面视图的代码与触发事件操作函数的代码分开。所以我想我现在有一个 MVC 安排（尽管我没有使用像 Backbone.js 这样现成的 MVC 框架）。
不过，我没有使用 HTML 模板。我认为 HTML 和编程之间 100% 分离感觉并不自然。我认为简单的编程循环、条件语句和 JavaScript 触发器都可以很好地与 HTML 配合。
I started using the same approach: JavaScript for the user interface layer and PHP for the database access layer. I'm using AJAX to pass all the data back and forth between the 2 layers. So far, AJAX has occasionally frozen on me, but it has been speedy enough most of the time. So I guess it'll work well enough.
(The result is that my code has gone from 90% PHP with 10% JavaScript...to 65% JavaScript with 35% PHP.)
I've also separated the code for my page views from the code for my triggered event action functions. So I like to think that I have an MVC arrangement now (even though I'm not using an off-the-shelf MVC framework like Backbone.js).
I'm not using HTML templates, though. I don't think it feels natural to have 100% separation between HTML and programming. I think simple programming loops, conditional statements, and JavaScript triggers all go nicely with HTML.
如果您认为有一个创建 html/js 引擎的主视图和几个带有数据流的 ajax 视图 - 在 MVC 术语中这将是相当好的。
If you will think it in the way that there is the main view that creates the html/js engine and couple of ajax views with the data streams - it will be quite OK in MVC terms imo.
网站本身有什么更有活力的事情发生吗？它是否可以做更多 AJAXy 的事情，动态刷新网站的某些部分等？如果是这样，那么拥有一个仅使用 Javascript 的网站可能是合理的。
由于这不是 Web 传统的工作方式，因此从服务器发送 HTML 仍然是基线。如果您的页面基本上是静态的，如果您想为较老的客户、可能禁用了 Javascript 的受众、可能对纯 Javascript 页面存在可访问性问题的受众、无法理解 Javascript 或搜索引擎的替代客户提供服务，您应该提供 HTML来自服务器的页面。这没有什么问题，直接、简单且万无一失。在客户端用 Javascript 重新发明轮子时需要考虑很多事情。除非您充分利用了此功能的潜力（例如，参见高度动态的 Facebook 或 Twitter 页面），否则对于您的用户来说，它可能带来的麻烦可能大于其价值。
Is there anything more dynamic going on on the site itself? Does it do more AJAXy things, dynamically refresh parts of the site etc.? If so, it may be reasonable to have a Javascript-only site.
Since this is not how the web traditionally works though, sending HTML from the server is still the baseline. If your pages are basically static, if you want to serve older clients, an audience that may have disabled Javascript, an audience that may have accessibility problems with Javascript-only pages, alternative clients that cannot understand Javascript or search engines, you should serve HTML pages from the server. There's nothing wrong with it, it's straight forward, simple and foolproof. There are many things to consider when reinventing the wheel in Javascript on the client side. Unless you have a good use for the potential this offers (see for example the highly dynamic Facebook or Twitter pages), it may be more trouble than it's worth to your users.
听起来您距离从 MVC 模式到 MVVM 模式仅一步之遥。
MVVM 非常适合复杂的用户界面（这正是您使用所有 AJAX 和 JavaScript 等创建的界面），因为在这种情况下，您的 HTML 视图将能够通过 JavaScript 充当控制器。有一个名为 Knockout JS 的库（警告：我从未使用过它，但看起来很有前途）。
It sounds like you are one step away from going from the MVC pattern to the MVVM pattern.
MVVM is ideal for complex user interfaces (which is exactly what you would be creating with all the AJAX and JavaScript and whatnot) because in this case your HTML view will be able to act as the controller via JavaScript. There is a library (warning: I've never used it but it looks promising) for this called Knockout JS.