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 回答