Question

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

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

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

所以我有以下结构：

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

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

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

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

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

这是一种正确的方法吗？

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

Answer 1

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

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

Answer 2

我没有使用过KohanaPHP，但它看起来像是一个“轨道灵感”的框架。在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
    }
}

似乎模型中的合法逻辑，但从现在开始，您的应用程序必须能够允许访客发布文章，或者它有缺陷，您需要编辑模型，然后将您的网站的其他应用程序/区域放在一起< / p>

采取这种情况：

您有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但在不同的逻辑下使用多个站点。

希望这有帮助。

Answer 4

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

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

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

因此，从技术上讲，业务逻辑是行为的一部分，行动本身也是模型的一部分。如果你这样想，这是有道理的：控制器处理用户交互并根据模型（行动+业务）呈现视图。

**错别字。

控制器与模型 - 需要解释

4 个答案: