PHP MVC模式+REST困惑

Question

我正在开发一个 PHP MVC REST API，它将使用 OAuth 来验证调用是否可以执行。

所以我的计划是为 Angular 2/4 应用程序开发它来处理 API 调用。

这个想法是创建一个结构，其中我的域(例如 test.com)将有一个子域 api.test.com。并从中获取 API 将要求调用。

在开始构建之前我想确认的是我的 MVC 后端结构。

Ref.Pic

• 模型将拥有所有逻辑
• 查看将是api.test.com/api/call演示文稿。在我的例子中输出 JSON。
• Controller 将接受输入 exmp:api.test.com/api/call 调用模型中的逻辑(如果调用是)正确。比调用将对呈现 JSON 的 View 使用react。它也将保存 OAuth......

我试图理解这个的整个概念，因为我已经尝试了好几次来构建它，但每次我都会陷入一堆困惑的代码。我想看看我对上面项目的理解是否使感觉。

谢谢

Answer 1

当您尝试申请SoC时，您会遇到多个问题。代码库中的原则。

而且，如何处理 View 和 Controller 之间的通信是更明显的问题之一。这是因为，如果你搞砸了，就没有抽象可以将其隐藏起来。

两种主要方法是Supervising Controller和自治 View (没有文章，但您可以从 this 和 this 推断出其中一些)。

监督 Controller

这种方法最适合较小的应用程序(嗯..对于较大的“小”值，因为非常小的项目并不真正需要 MVC 的架构膨胀)。它本质上看起来像这样:

/* in a controller */
public function verifyEmail(Request $request)
{

    $identity = $this->search->findEmailIdentityByToken(
        $request->get('token'),
        Identity::ACTION_VERIFY
    );
    $this->registration->verifyEmailIdentity($identity);

    $body = [
        'status' => 'ok',
    ];

    return new JsonResponse($body);
}

本质上，您拥有的是一个 Controller ，它与业务模型交互并(在必要时)用数据填充 View 。然后它导致 View 被渲染并返回响应。

根据我自己的经验，我发现这是编写后端应用程序时最好使用的方法，这些应用程序预计只能通过类似 REST 的 API 进行操作。

正如您在示例中看到的，本例中的“ View ”非常简单。它基本上是数组，您渲染为 JSON(提供的代码实际上会这样做 - 它是从真实项目复制的)。

Note:
If your intention is to fully implement REST as it was proposed (not just the REST-like resource endpoints) and/or have functionality of resource expansion, then this approach might be wrong and even harmful.

自主视图

当您的表示逻辑变得复杂或必须为具有相同功能的同一应用程序提供不同的 UI(例如同时具有网站和 REST API 的单个应用程序，同时具有 xml 和 json 接口(interface))时，使用监督 Controller 就变得很困难和你脖子上的链子。您的 Controller 开始不受控制地增长，您的项目甚至在投入生产之前就可以被描述为“遗留代码库”。

这就是您使用这种方法的地方。

您将 View 和 Controller 用作完全独立的类，并在同一层(例如:引导阶段)交互它们的实例。它最终看起来像这样:

/* in /src/application.bootstrap.php */
$command = $request->getMethod() . $parameters['action'];
$resource = $parameters['resource'];

$controller = $container->get("controllers.$resource");
if (method_exists($controller, $command)) {
    $controller->{$command}($request);
}

$view = $container->get("views.$resource");
if (method_exists($view, $command)) {
    $response = $view->{$command}($request);
    $response->send();
}

同样是来自另一个实时项目的示例，该项目也使用 DI 容器。在这种情况下，只有一个 UI(因此，在创建 View 实例时，没有“类型”前缀)，这意味着代码可以利用 Controller View 之间的 1:1 关系(如果您这样做，则为 1:n)需要多个 UI)。

在这种情况下， Controller 基本上只“写入”模型层。并且 View (也可以访问模型层的服务)仅执行“读取”并提取仅填充模板和渲染模板所需的信息。

而且，如果您的表示逻辑进一步增长，最好开始添加 presentation objects ，它将包含表示逻辑的重复部分(例如，决定必须展开侧边栏中的哪个菜单项以及必须突出显示哪个子菜单项)，这对于多个 View 来说很常见。

如果您的后端应用程序仅处理 API，那么这种方法可能太复杂，除非您正在执行“注释”部分中提到的操作之一。

_{...也许这有点帮助}