在php">fleaphp中,mvc这三个部分不同的体现.
V---最简单,几乎没有它的位置,他的活,基本上是由模版(如smarty)来干,V本身在MVC的结构中没有多大的比重.毕竟,一个成熟的模版可以解决几乎所有问题.除非,有人用上自己写的模版系统,或者为该MVC定制一个模版.
M---最辛苦,理论上,所有苦活累活都是M的事.比如说,添加数据,检索数据库等等等等.但,在实际代码的写作中,M却不是一个需要程序员花太多时间跟力气的地方(在这里,是指的利用FleaPHP做二次开发).
FleaPHP中已经集成了许多的功能.程序员在写程序的过程中,只要找准合用的调用就可以了,不要客气.
所以,在FleaPHP(估计别的MVC系统里应该也一样)里,程序员涉及到的M部分.大体就,也只有简单的几句,也不过是诸如,调用哪部分的功能,在调用该功能的时候,添加一些参数了.
整个FleaPHP,大概有80%以上部分承担着M的工作.
C---最复杂.所有程序员的工作基本都集中在这里了.每一个功能应该如何完成,每一个功能应该分成几个模块,都要在这里体现出来.大家个人水平的高低,也就是在这里体现出来了.
结语,FleaPHP就象是给我们提供了一整套的标准零件,能够搭出什么机器来,就要看自己的了.而搭机器的功夫,就体现在C上面.
dualface
引用:
V---最简单,几乎没有它的位置,他的活,基本上是由模版(如smarty)来干,V本身在MVC的结构中没有多大的比重.毕竟,一个成熟的模版可以解决几乎所有问题.除非,有人用上自己写的模版系统,或者为该MVC定制一个模版.
是的，V 本身的工作就是呈现内容，提供一个用户界面。所以就是用通常的模版技术就可以解决。
引用:
M---最辛苦,理论上,所有苦活累活都是M的事.比如说,添加数据,检索数据库等等等等.但,在实际代码的写作中,M却不是一个需要程序员花太多时间跟力气的地方(在这里,是指的利用FleaPHP做二次开发).
FleaPHP中已经集成了许多的功能.程序员在写程序的过程中,只要找准合用的调用就可以了,不要客气.
所以,在FleaPHP(估计别的MVC系统里应该也一样)里,程序员涉及到的M部分.大体就,也只有简单的几句,也不过是诸如,调用哪部分的功能,在调用该功能的时候,添加一些参数了.
整个FleaPHP,大概有80%以上部分承担着M的工作.
FleaPHP 中本质上没有为 Model 提供什么支持。但是，由于我们日常开发的大部分应用程序，逻辑部分都是很简单的 CRUD（数据记录的创建、读取、更新和删除）操作，所以 FleaPHP 的 TableDataGateway 正好可以作为大部分 Model 的基础。
你可以在 TableDataGateway 基础上派生自己的类，从而通过提供自定义方法来实现各种业务逻辑。
但是，当业务逻辑逐渐变得复杂时，这种做法也有弊端。所以这个时候，就需要将自己从 TableDataGateway 派生的 Model 类分为两部分。
第一部分还是一个 TableDataGateway 的派生类，但只负责所有的数据库操作。和业务逻辑相关的部分保留在第二部分中。第二部分就是一个纯粹的 Model（模型），只提供业务逻辑服务。
这样一来，应用程序的控制器 -- 调用 --> Model 进行业务操作 -- 调用 --> TableDataGateway 派生类完成数据库的实际操作。这种分层对于较大的应用程序是非常必要的，可以让应用程序的结构更清晰，便于以后的扩展和维护。
有关这样做的实际效果，可以参考 FleaPHP 中的 SHOP 示例程序。
引用:
C---最复杂.所有程序员的工作基本都集中在这里了.每一个功能应该如何完成,每一个功能应该分成几个模块,都要在这里体现出来.大家个人水平的高低,也就是在这里体现出来了.
本质上，控制器（Controller）应该是很简单的。通常只是负责对用户输入的数据（$_GET、$_POST 等）进行一下简单的检查和处理后，调用 Model 来完成实际的业务操作。
比如在 FleaPHP 的 SHOP 示例中，删除指定的产品，是这样做的：
代码:
/**************************** 控制器代码 ************************************/
function actionRemove() {
$this->_modelProducts->removeProduct($_GET['id']);
$this->_goBack();
}
/**************************** Model 代码 ************************************/
function removeProduct($productId) {
// 删除产品前，需要先删除该产品的图片文件
........
// 删除缩略图
........
// 删除所有大图片
........
// 从数据库实际删除产品的记录
return $this->_tbProducts->removeByPkv($productId);
}从上面的两段代码可以看到，控制器没做任何实际工作，仅仅是将用户输入（$_GET['id']）作为参数，调用了 Model 的 removeProduct() 方法。
而 Model 的 removeProduct() 方法，在删除了产品的图片文件后，并没有直接操作数据库，而是调用 $this->_tbProducts 的 removeByPkv() 方法删除了产品。这样一来，Model 实际上就和数据库操作（通常会充满 SQL 语句）隔离开了。
所以在应用程序开发中，程序员工作量最大的部分还是 Model 和数据库操作。但由于 FleaPHP 的 TableDataGateway 为数据库操作提供了很多方便的手段，因此程序员最终可以把大部分精力放在如何实现业务逻辑（也就是实现和完善 Model）上了。
浪子快刀:
继续我的观点.
个人觉得,一个成熟的系统,应该能够把我们想到的和没有想到的功能都做在里面了(这么说,可能有点夸张).打个比方,比如说,Word,那里面有了许多许多的功能.我们拿过来用就是了.不需要想怎么实现的.
所以,我上面说的M比较简单的意思是.M这部分工作,不应该太复杂.理由如下:
1 FleaPHP本身会提供很强大的功能,作为使用者的我们来讲,会用就可以了,不需要考虑如何才能达到这功能.
2 如果是一个使用FleaPHP较久的人,他本身就已经积累了许多M相关的内容,而这内容是可以重复使用的.
3 当然,作为一个程序员,完成功能是应该做的事.但,这工作本身就有一个唯一性.一个功能完成了,以后相同的功能,就可以直接用了.不需要重复完成(这个讲的有点乱,大家见谅哈)
再举一个比方.拿战略跟战术来做比较.
战略--是指,要不要打,什么时候打,在什么情况下打,什么情况下不打,---有点C的味道吧?
战术--是指,怎么打,具体到,一个山头怎么打,一条河怎么抢渡等等,---有点M的味道吧?
个人觉得,M是做具体工作的,C是做指导工作的.而,电脑的特性决定了,在一段时间内,M是可以完成的(所有功能都完成了),而C是没有尽头的(每一个新的网站总是有许多新的情况发生).
所以,在某种意义上,C应该复杂过M.
只是个人观点,大家讨论.呵.
顺祝大家开心.
最近工作忙,电脑又中标,大家就表象我这样子.
dualface
M 不大可能做到尽善尽美，所以需求变化的时候，M/C/V 都会有所变化。
其实现在追求的快速开发，就是希望能够用最短的时间应付需求的变化。
freechoice
我认为按照三层式开发的角度来看，其实也没那么复杂
V 当然就是表示层了，没说的
上面说的没错，这里是放模板的，当然smarty我还没用，用的是其它的模板类库
C 为逻辑层
是用来处理表示层和数据层的关系的，因此这里的工作最为繁重。
Db 为数据层，还是把M归到这里来吧（其实说白了这应该归到逻辑层去，他做的工作还是在逻辑层的）
对数据库的操作
skyblue
在用fleaphp开发时
C包含的每个内容都很好确定,V层面上有什么操作,C中相对应一个action就是了,然后调用M中的一些方法组合完成任务.
个人认为,比较麻烦的还是M功能的分解.
如何分解每一个功能以提高其重用性,是我目前最头疼的问题...
写程序,完美主义有时候也是很大的障碍啊..郁闷...
我现在就在跟自己过不去...半夜三点多上来发发牢骚....
dualface
引用:
写程序,完美主义有时候也是很大的障碍啊..郁闷...
确实如此。只要应用此程序具有较好的基础架构，我们就可以相对容易的通过“重构”逐渐改善应用程序。
从我的实际经验看，在一开始实现应用程序时，不大可能做到很好。只有在开发过程中和维护过程中，不断总结经验教训，不断重构，才能获得更好质量的应用程序。
ToToDoDo
如果楼主还感觉不到M层的复杂和工作量，或许是因为本身实现的功能相对比较简单的展示性功能。
这时候由于Fleaphp对数据库查询以及关联操作封装，因此M层相对C来说写的代码和结构上要简单清晰些。
M恰恰是不可能绝对完善的，感觉楼主所说的M是业务逻辑中的扩展功能和其实现，这应该算作M的扩充辅助。而M本身强调的是业务逻辑，因此我觉得Fleaphp最重要还是需要一个灵活且扩充性良好的结构思路，不过这也是最难求的。。。
dualface
是的。业务逻辑其实是最复杂的部分。只不过我们做的大多数网站就是简单的对数据库进行 CRUD 操作，所以 M 反倒变得简单了。
要想针对业务逻辑实现一个灵活且扩充性良好的结构，目前还没想到好办法。
