今天业务完成到一定程度，查看下代码，猛然发现目前的这个代码有点奇怪。奇怪就奇怪在我的model中有很多文件，每个文件都对应数据库中的一张表，然后每个model中有很多是几乎没有什么逻辑代码的。比如：

这个原因是什么呢，因为rdb_model这个类实现了ORM，我继承这个类才能使用ORM的那些操作。

但是这个确实让我很不爽，一个神马东西都没有的类为什么要写呢？引申出的一个问题是到底是胖model好呢，还是瘦model好？

不难想象我项目中的代码算是胖controller，瘦model了。即我的model完成了ORM的封装流程，为的就是controller中能更方便使用。说实话，这样controller中的函数写下来是非常舒服的。但是考虑一个问题，这样子是不是违反了DRY原则呢？如果是瘦到只封装ORM的model，那么一定可以闭着眼睛说，controller中一定有很多会冗余的代码。这确实是不好的做法。controller中的冗余可共用的代码并没有抽象出来，这当然会造成日后的代码困扰。

那我们退一步，如果model不再那么瘦呢？我们把基础的一些方法都放到model中，但是我们还是坚守着一个表一个model的方法。那么就会将下面这样的方法放到model中：

问题就是，这里势必要使用comment_model了，这个model是comment表的映射，它的内部却是任何功能都没有实现。

如果你会说这样其实没有什么问题，那么下面问题来了，现在访问量上来了，我们不从DB中取出数据了，我们改成从DB中取出数据，存入缓存，然后下次再去缓存中取数据。这时候的问题来了，缓存是加在controller中还是model中呢？

这个观点各执己见，从领域驱动模型来说，缓存是不属于领域模型范畴的，它和领域数据逻辑没有关系，它属于应用层范畴。但是从MVC观点来看，Model层是数据获取的抽象，controller层只管理数据的重新组织和连接，数据从哪里来并不属于controller管理范畴。所以呢，数据从DB中来还是从Cache中来，这是Model层应该管理的。

如果再退一步呢？所有的数据逻辑都写在model中呢？那么就会出现下面这个看起来奇怪的代码了：

一个方法只有一行！！如果增删改查都这么做，就很冗余了。这么多本来可以不用写的代码总是让人非常不爽。在调用的时候反正都是一句话的事情，为什么还要封装一层呢？

我想所有的分歧先要弄清的是MVC的model是什么的抽象？如果说model是数据结构的抽象，那么ORM就已经完成了这个抽象行为，一个DB一个model就是实现这样的抽象。但是我觉得并不是这样的。model应该是业务逻辑上的抽象。就是说，model层应该是触及到了具体的业务逻辑，它把业务逻辑封装成了可以给controller调用和使用的语言。这就非常符合领域驱动设计的意思了。model层是将业务领域封装成模型的层。算是一种“翻译”工作，将现实中的业务“翻译”成程序语言。这样的model封装才有意义。

然后回到缓存放在controller还是model的观点。我认为，业务领域获取数据是从缓存还是DB中获取，这个逻辑应该是放在model中的，因为这个也属于“翻译”的过程。如果这个逻辑由应用层来做的话，它就需要关心到这个访问和那个访问是不是同时都使用了缓存，返回的数据是不是一致的这样一致性问题。那么就是把这层和实际的“运行环境”的逻辑放在本该很清晰的应用层来做了。

但是呢？老子说的，不同情况不同分析。

做前台和做后台是一样的逻辑吗？这里说的前台是指API，WEB，WAP等方式。后台指的是运营，审核等后台。我的观点就是前台尽可能或者强制性地“胖model”化。意思就是所有可以零散放在model中的访问都在model中放着。这个观点就默认了

这样的写法在前台是合理的。如果在cars这个表上面加个缓存，那么只需要修改model中的三个方法，不需要修改业务的应用逻辑！！这样就把模型在具体环境的实现完全抽象化了。

但是对于后台呢？后台实际上是对实际数据的强行干预了。所以我们在后台很少触碰到缓存等优化机制的。并且鉴于后台开发不需要承担大并发的需求，也往往开发时间紧张于前台。所以后台开发这种“胖controller，瘦model”的模型非常适合的。甚至于能用到“胖controller，无model”我认为也不算过分。

所以再次举起具体问题具体分析的大旗，这个问题算是有结论了。