4

这是用一个控制器处理普通和 ajax 调用的好习惯吗：

<?php

class SomeController extends Controller {

    function index() {

         if(!$this->input->is_ajax_request()) {
             // load model
             // create form
             // pass data to view
             // ...
         } else {
            // validate input
            // load model
            // write data to database
            // return with some json string
         }

    }

}

有什么优点和缺点？

4

4 回答 4

3

简短的回答：这取决于。

XHR（营销人员称之为“AJAX”）和普通浏览器请求之间唯一真正的区别是 XHR 期望不同形式的响应。

在受 MVC 启发的 Web 模式中，负责生成响应的部分是视图实例。视图应该识别它必须产生什么样的响应，并采取相应的行动。在这种情况下，控制器的作用只是改变当前视图的状态。

或者，您可以在引导阶段检测AcceptHTTP 标头，并基于该标头初始化不同的视图实例。

“完全实现视图”是指一个实例，它包含 MVC 三元组中的 UI 逻辑，并且可以决定响应哪个。该响应可以是 HTML 文档，由多个模板、JSON/XML 文件或只是一个简单的 HTTP 标头组成。

  • 优点：适当的关注点分离，更易于维护
  • 缺点：必须实现完整的 MVC

.. 但大多数人不使用完整的 MVC 实现。

如果您是这样的人，而不是 MVC 启发的模式，而是使用关于页面控制器模式的类似 Rails 的变体，那么您将被迫创建一个单独的控制器来处理 XHR。

在这种情况下，没有真实的视图。它被哑模板替换，而 UI 逻辑已合并到页面控制器中。在这种情况下，唯一实用的选择是创建一个单独的控制器来处理 XHR。

  • 优点：在小型项目中更易于实施
  • 缺点：可能的代码重复，更难维护
于 2012-11-08T13:59:02.900 回答
2

即使是 AJAX 请求，您仍然需要验证输入。不是您向您的应用程序发送输入（通过 AJAX），而是浏览器，您无法信任。

作为一般设计原则，避免特殊情况（此处：ajax 与非 ajax）。通常，您希望平等对待所有情况，因此您最终会采用正交方法。

正如你所看到的

class SomeController extends Controller {

    function index() {

         if(!$this->input->is_ajax_request()) {

             // validate input <-- XXX here we need to validate it too

             // load model
             // create form
             // pass data to view
             // ...
         } else {
            // validate input
            // load model
            // write data to database
            // return with some json string
         }

    }

}

这会导致重复代码（难以维护和保持同步）。

您的代码，正交方法：

class SomeController extends Controller {

    function index() {
         // load model (takes care of his own validation, the self-containment principle of OOP)
         // coordinate same business logic done by different models
         // return models/data to the view, the framework will decide whether it uses the html or the json view file
    }

}

相反，模型（它可以是相同的模型类，或者像 Zend Framework 中的 Form 模型，或者像 ZF2 中的 hydrating 方法可以完成大部分工作（连同 Table Gateway、DAO（如Doctrine 2) 或模型的类似类），您可以为 HTML 和 JSON 创建两个单独的视图。

例如，在 Zend Framework 2 中，为您透明地选择了正确的视图，因此实际上不会有任何关于“这是 AJAX 还是不是？”的 if/else。

您应该尝试使用现代 PHP 框架(5.3+) 来了解如何使用PHP 来设计您的应用程序。

于 2012-11-08T13:45:51.830 回答
0

我认为这是开发人员的选择，考虑一下：

我认为这是开发人员的选择，请考虑这一点。我见过的一个客户端移动网站的开发。他们有一个网络商店和一个模型商店：

/store/model/order.php
/store/controller/order.php
/store/view/order.php

而不是

/store/model/order_mobile.php
/store/controller/order_mobile.php
/store/view/order_mobile.php

管理是一场噩梦。为移动客户端分离图像、css、多个编码副本。他们现在的解决方案是将整个网站转换为响应式设计

/new-dev-store-responsive/model/order.php
/new-dev-store-responsive/controller/order.php
/new-dev-store-responsive/view/order.php

相同的代码但更干净。而且我会在我的模板中使用 PHP 结构在某些代码上进行 AJAX 调用，而在其他代码上没有。同样，它可能难以管理。最好使用 JSON 或外部静态文件来处理 - 所以 PHP 是使用 GET、POST 等驱动的。如果他们有 JavaScript，AJAX 可以与 PHP 一起工作。PHP 代码应该保留 PHP IMO 。

/new-dev-store-responsive/model/order.php
/new-dev-store-responsive/controller/order.php
/new-dev-store-responsive/view/order.php

//new-dev-store-responsive-cdn.com/assets/js/order.js
//new-dev-store-responsive-cdn.com/assets/css/order.css
//new-dev-store-responsive-cdn.com/assets/imgs/order/checkout.jpg
于 2012-11-08T13:42:45.707 回答
0

您的方法有一些优点和缺点。

对于发布公共数据，没有问题。

对于获取公共数据，我通常更喜欢在单独的控制器中进行，很多时候我什至不进行 ajax 检查，因为我的数据是公开的，我希望它尽可能地去。

对于发布/获取私人数据，我不喜欢使用这两个方面的方法，因为拥有良好且干净（安全）的代码会更好......

无论如何..一切都取决于您的选择。一切皆有可能！并且没有正确的常数和不正确的常数..

于 2012-11-08T13:48:10.523 回答