控制器与模型 - 需要解释

Question

我正处于“学习 MVC”之路的开始。基本上，我对面向对象编程没有什么大问题，但是有一个技术方面需要澄清。看来我的理论还不够完善。

目前，我正在使用 KohanaPHP 框架，版本 3。

示例情况： 我有一个网站，用户可以在其中提交文章。

所以我有以下结构：

classes/
    /controllers/
        article.php
    /models/
        articles.php

到目前为止一切顺利。我对扩展 Kohana_Model 的模型没有任何问题，但是我不确定我是否使用使用 ORM 的正确方法模型。

基本上，当使用扩展 Kohana_Model 的模型时，我会将所有逻辑操作放入模型中。我应该对使用 ORM 的模型做同样的事情吗？在网络上的许多示例中，我看到控制器对数据库中的用户输入/数据执行逻辑操作，我认为这是不正确的。

假设我需要从数据库中获取几行，因此我在模型中创建正确的方法并返回对象。我认为这是正确的，不是吗？

基本上，对用户输入/数据的所有操作（从数据库中选择、插入数据库、验证）我都放在模型中。这就是我理解MVC设计模式的方式。模型应该关心所有“机械”操作，控制器只是模型/视图之间的“桥梁”，它是一个“前端”引擎。

这是正确的做法吗？

我知道对于更高级的用户来说这可能是一个愚蠢的问题，但我只想学习好的实践。如果有人能提供一些澄清，我会很高兴。

Answer 1

简而言之，您的模型对数据执行所有操作（无论是传入、传出、数据库、文件......数据），并且您的视图应该负责显示数据。控制器应该调用必要的模型方法来准备将数据传递到视图。控制器不应对数据执行任何更改，但应对其进行测试以正确完成必要的操作。

希望我说得足够清楚，如果这对您来说还不清楚，请告诉我。

Answer 2

我没有使用过 KohanaPHP，但它看起来像是一个“受 Rails 启发”的框架。
在 Rails 世界中，通常认为最佳实践是使用瘦控制器和胖模型。

一些背景可以在 jamis Buck 的这篇旧文章中找到 http:// /weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model 或在这一篇中有关 cakephp http://gluei.com/blog/view/cakephp-best-practices-fat-models-and-skinny-controllers

Answer 3

将逻辑与数据分离的想法是数据不包含逻辑，因此在模型中您应该只真正清理数据。

举个例子：

public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id = false)
    {
        if(!$user_id)
        {
             $user_id = get_guest_id();
        }
        //Insert
    }
}

模型中的逻辑似乎是合法的，但从现在开始，您的应用程序必须能够允许访客发布文章，否则它有缺陷，您需要编辑模型，这将影响您网站的其他应用程序/区域

采取这种情况：

您有 2 个站点

• ComputerArticles.com
• CookingArticles.com

现在，这 2 个域指向同一台服务器，但在 kohona 中是一个单独的应用程序，不要在模型中放置任何域逻辑，您就可以在所有域中使用确切的示例模型。域。

您的模型方法应该如下所示：

public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id)
    {
        $this->compile("articles",array($title,$text,$user_id))->insert();
    }
}

在您的控制器中，您应该放置所有逻辑，因为逻辑将取决于域。

将您的模型视为一个 API，其中您有多个站点使用相同的 API 但在不同的逻辑下。

希望这有帮助。

Answer 4

以下是术语的基本外行定义 -
视图：呈现给用户的屏幕
控制器：接收请求、确定谁处理请求并适当地委派它们的引擎/框架。
模型：这基本上告诉您在该屏幕上完成某某操作后要显示什么屏幕。将其视为一个（有向）图。从节点出现的边是动作，它们连接到的节点是基于这些动作的下一个屏幕。

因此，模型基本上包括用户在屏幕上执行的操作及其操作处理程序。控制器只是为特定的用户操作调用相应的操作处理程序，并且操作处理程序负责对传入的请求执行一些明智的操作。

现在你的问题。业务逻辑去哪儿了？
嗯，它是动作处理程序。或者它被抽象到人们喜欢称之为的某个地方——业务层。但无论如何，它是由动作处理程序本身触发的。

因此，从技术上讲，业务逻辑是操作的一部分，而操作本身也是模型的一部分。
如果您这样认为，这是有道理的：控制器处理用户交互并基于模型（操作+业务）呈现视图。

** 已更正拼写错误。