#1 xoYu

jake之前的例子都是直接在控制器里用find findall 读取数据、、
前几天看见有人写在模型里  代码如下
class lib_admin extends spModel
{
public function data_find($conditions)
  {
    return $this->find($conditions);
  }

  public function data_delete($id)
  {
    return $this->delete(array('id' => $id));
  }

  public function data_add($row)
  {
    return $this->create($row);
  }

  public function data_update($conditions,$row)
  {
    return $this->update($conditions,$row);
  }


这两天忽然觉得有点多此一举
因为模型本身就是继承自sp模型父类
这样徒增几百行代码啊


你怎么看 jake？

2013-03-17 19:22:38

#2 jake

这个问题得从头好好说起，其实我曾经也有一段时间很困惑。

首先说明一下我对上面代码的看法，没有赞同或者反对的意思，不过我也不喜欢多余的代码 —— 这不代表别人不喜欢，下面会说到。

关于M层，乃至于类库的封装，一直都有各种各样的意见，比较传统的是“无论如何也要封装”的思路，这个思路从何而来就难说，不过把它发扬光大的，是Java。—— 而且这种思维，也被很多“把PHP当成Java来写”的人，带到了PHP的领域。

如果你看过Java的代码，都会有个印象：为什么哪些人写代码都喜欢绕来绕去的，明明是个很不重要的类，都要写一堆setter和getter函数，直接读类的成员变量不好吗？—— 就好像，Java的类里面，成员变量永远也只能是private，然后通过setXXX和getXXX来使用。

估计是因为Java是预编译型的语言，而且还是把预编译好的class文件可以到处用，所以给开发者的感觉就是：如果是我提供给别人用的class，那么一定要“适应变化”，否则当需求变化后，class文件无法修改 （这是Java的印象，其实Java也可以改的，而且现在做Java项目的人，几乎都在改），那么就惨了。像《Thinking in Java》这种权威的书籍，几乎在每个地方都提倡这种心态：“不管如何，我写的每个类都要有这种“扩展性”，否则别人会怪我”。

我觉得，上面这种心态，就是认为代码是“静态”的，或者说是“死”的，它们永远也不会变，永远也需要参与项目的每一个开发者，都做好“以不变应万变”的准备，不管一万年后，代码是真的要扩展，还是一万年都没有任何扩展。不过这个逻辑很矛盾——既然你不知道它会在什么地方变化，那么你怎么能做好应对变化的措施呢？

当然我不是批评这种做法，也只是描述一下有这种做法的存在而已。那已经是一种传统习惯，不好评论。

不过我更提倡的是“代码是活”的，面向对象也好，MVC也好，其实已经提供了非常好的扩展性，比如spModel，如果之前你是一直在Controller里面用find/findAll，那么当你需要“扩展”的时候，你可以在spModel的继承类中，直接覆盖find/findAll，那么就能达到你要的效果。因为代码是活的，面对什么样的需求变化，就做什么样的应对，你的地盘你做主。不过当你还没需要的时候，倒不如赶紧把需求完成，上线。然后再“勇敢地拥抱变化”。

2013-03-17 19:56:05

#3 xoYu

感谢jake细致回答  实际上我也是觉得重复利用的写在模型里是没问题。
如果没有改变 单纯增加几行代码 从控制器搬到模型里 还是意义不大。

所以今晚又改回来了 :lol

2013-03-17 20:05:43

#4 jake

其实我之前困惑的问题是：如果一直在Controller里面写find/findAll，那么整个项目看起来就是“大C小M”了。

一般而言，比较正规的MVC，都是“大M小C”的，那么这样是不是不好的MVC实践呢？

后来我才想明白，虽然我在用的M层是很小，但是别忘了，spModel很大。依靠面向对象的继承特性，摒除重复性的代码，然后把M层变得看起来很小但是能实现全部M层的功能，而且带一定的“扩展性”，那么何乐而不为呢？

所以，小M大C只不过是错觉，在背后，spModel做了很多很多M层的工作，它才是真正的M层（的一部分），M层的大小，不在乎是写多少代码，而是业务的复杂度。

如果业务非常复杂，非常非常复杂，那么大M是肯定的 —— 这时候 C还是和原来一样（你能做到吗？），这才是真正的MVC架构。

2013-03-17 20:12:41

#5 jake

刚才在微博内，有网友评论，也很有道理。补充一下：


小M的另外一个可能性，也是因为业务重复率较低的情况下，M没办法进行复用，或者复用的次数非常少（两三次），那么，就没必要把这些代码都堆到M里面。

2013-03-17 23:05:49

#6 xoYu

不错 我现在也是这个想法 模型父类本身已经完成了很多
复用性不强的、一行代码搞定的  没有必要再去重复写在模型里。

2013-03-18 00:00:34

#7 php菜鸟

我也学习了{:soso_e113:}

2013-03-18 10:11:06