2011-01-11 93 views
13

我正在开始“学习MVC”的方式。基本上,我没有面向对象编程的大问题,但是有一个技术方面需要澄清。看来我的理论还不够好。控制器与模型 - 需要说明

目前,我使用KohanaPHP框架,第3版。

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

所以,我有以下结构:

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

到目前为止好。我没有模型扩展Kohana_Model的问题,但我不确定我是否使用了正在使用ORM的正确方式模型。

基本上,当使用模型扩展Kohana_Model时,我会把所有的逻辑操作放在模型中。我应该对使用ORM的模型执行相同的操作吗?在网上的很多例子中,我看到控制器对用户输入/数据进行逻辑操作,这在我看来是不正确的。

比方说,我需要从数据库中获得几行,所以我在模型中创建适当的方法并返回对象。我认为这是正确的,不是吗?

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

这是一个正确的方法吗?

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

+0

这不是一个愚蠢的问题。该主题只是混淆,因为原来的[MVC模式不匹配web应用程序中的处理](http://stackoverflow.com/questions/1549857/simple-php-mvc-framework/1549970#1549970)。所以不要试图找到“正确”的方法。通常最适合使用类似PMVC的结构,其中模型仅仅是未知的数据库接口。 – mario 2011-01-11 10:12:33

回答

41

总之而言,你的模型对数据进行的所有操作中找到(无论是传入,传出,数据库,文件...数据),您的视图应该照顾显示数据。控制器应该调用必要的模型方法来使数据准备好传递给视图。控制器不应对数据执行任何更改,但应对其进行测试以正确完成必要的操作。

希望我已经说得够清楚了,让我知道如果这不能为你解决问题。

2

我没有使用KohanaPHP,但它看起来像一个'轨道启发'框架。 在钢轨领域,通常认为最好的做法是使用瘦身控制器和胖模型。

一些背景可这个老文章了Jamis降压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

+0

感谢您的回答。我要去选择poelinca的答案是正确的(你的答案也是正确的),但你得到更多的分数;-) – 2011-01-11 10:28:07

+0

嘿,不再; – roman 2011-01-11 10:31:17

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的站点但使用不同的逻辑。

希望这会有所帮助。

0

下面是术语的基本外行定义 - 浏览:呈现给用户 控制器的屏幕:发动机/框架,它发生在请求,决定谁处理,并适当地代表他们。 型号:这基本上告诉你什么屏幕显示后,所以在这个屏幕上完成操作。把它想成一个(定向)图。从节点出现的边缘是动作,它们连接的节点是基于这些动作的下一个屏幕。

因此,一个模型基本上包括用户在屏幕及其动作处理程序上执行的操作。控制器简单地调用相应的动作处理程序来处理特定的用户动作,动作处理程序负责对传入的请求进行一些合理的处理。

现在你的问题。业务逻辑在哪里? 嗯,它是行动处理程序。或者它被抽象到人们喜欢称之为业务层的地方。但无论如何,它是从行动处理者本身引发的。

因此,在技术上,业务逻辑是其本身是模型一部分的一部分行为。 如果您这样认为,这是有道理的:控制器处理用户交互并基于模型(操作+业务)呈现视图。

**错误更正。