19

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

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

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

所以我有以下结构：

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

到现在为止还挺好。我对扩展 Kohana_Model 的模型没有问题，但是我不确定我是否使用了使用 ORM 的正确方法模型。

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

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

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

这是一个正确的方法吗？

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

4

4 回答 4

67

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

希望我说得足够清楚，让我知道这是否不适合您。

于 2011-01-11T10:15:40.943 回答
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

于 2011-01-11T10:14:16.663 回答
1

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

举个例子：

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

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

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

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

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

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

希望这可以帮助。

于 2011-01-11T10:33:58.647 回答
0

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

因此，模型基本上包括用户在屏幕上执行的操作及其操作处理程序。控制器只需为特定的用户操作调用相应的操作处理程序，操作处理程序负责对传入的请求做一些有意义的事情。

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

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

** 错别字已更正。

于 2011-01-11T10:34:20.253 回答