应该在model层里做些什么？
有些东西不知不觉都写进了 controller 层里了，不知道应该在model层里做些什么，希望达人能贴些model的代码让小弟学习学习。 有个概念叫三层结构即，表现层，业务逻辑层，数据持久化层
一般把controller+view看成表现层
业务逻辑层和数据持久化才是工作的重点
一般来说框架有个目的就是希望程序员更专注于项目业务逻辑
ci，我认为应该和rails是相同的哲学理念，他的业务逻辑和model紧密联系
称为rich model，基本把业务逻辑整合到model里，但似乎我的这种理解目前看来有问题
如果业务逻辑不在model里处理，但就需要专门有个Service层来主力处理业务逻辑问题
但至少我至今没有看到类似的best practice，不过有一点肯定就是在controller只应该专注view的表现
如果里面过多涉及业务上的问题，肯定是欠妥的
当然这些都是业务逻辑比较复杂的时候才会碰到
如果只是做些crud，那就随便怎么样都无所谓了 举例
我还是觉得应该 rich model
<?phpif (!defined('BASEPATH')) exit('No direct script access allowed');
class ArticleModel extends MY_Model{
public $tableName = "article";
function ArticleModel(){
parent::MY_Model();
}
#......
#省略
/*
* 删除文章！
* blog的文章，文章下有评论
*文章还属于特定的某个category
* 删除文章下的所有评论，更新当前文章所在category的文章总数统计
*/
function remove($article_id){
//原子操作
//do transaction
//得到article
$article = $this->get_by_id($article);
//删除所有评论
$this->comment_model->remove_by_article($article);
//更新category文章数目统计
$this->category_model->update_sum($article);
//删除文章
parent::remove_by_id($article_id);
//end transaction
}
}
?>
View <－－－－－－>Controller
\ /\
\ /
\ Model <－－ /
|
\|/
Database
MVC模式，通俗的理解：用户通过View把请求的操作（数据）传递给Controller，Controller负责把操作指令传递给Model（调用相应的方法），Model会处理这些具体的指令（CURD），之后把结果返回给Controller，Controller再根据结果来控制View的呈现。故一般的，把对数据库操作（CURD）放在Model。 model 主要由两部分组成：
数据的操作（CRUD）
数据的验证（validation）
controller 只管处理I/O （input/output）的逻辑，至于逻辑的内部结构则交由model去处理。所以，controller里的代码越精简越好。 楼上有道理，不过还是有点范一般枢架MODEL层只搞数据库的偏见，也是一点失误。
我也是有这种思想，只在MODEL层搞数据库。
不过，最近看了一些文章，在MODEL层还是可以搞其它的。。
如搞一些图型，文件上传，还有一种常见的例子就是无限分类的目寻生成。等。。
总之，做站用到的所有函数都可以在MODEL上定义，不过这样有点不合情理。 所谓的“数据”，并不单指数据库而已。:)
简单地说，“功能性”的东西大部分都能放model里。 把什麽都扔到model去处理，这样很好么，让controller弱化成为数据传输通道而已，这是最新先进做法？
好处是什麽呢？这么做很高效？
页:
[1]