建立控制器模型，舍弃建立数据库表模型（laravel 5）

入职了新公司，开始接手公司的项目，了解一段时间公司的业务后就开始搭建服务器的架构和一些选型。

最近1年都在使用 laravel 4.2 这个版本的框架进行项目开发，再次为项目框架选型，还是首先了laravel，这个框架用下来的感觉确实不错，这里就不再描述laravel框架的一些特性，可以自行查看中文站点：http://www.golaravel.com。

目前laravel目前的最高版本是5.1（LTS），最终考虑下来选择了5..0的版本作为项目开发，和之前一直使用的4.2的版本相比变化确实很大，尤其是对目录的管理，良好的文件管理也是项目架构设计重要的一个环节，在中大型的项目中尤为重要，可能在使用的过程中会稍显繁琐。另外我比较喜欢的就是route的隐式控制器路由，在中大型项目中route.php文件中的路由将更为简洁；引入中间件（升级版的filters.php）；依赖注入模式的运用等等。更多的介绍同样去访问laravel中文网，那里有详细的介绍。

很多的变化中，最让我感到疑惑的就是laravel 5的版本中把 app/models 这个文件夹给移除了，但是所有的定义都在，只要你在app目录下（或者其他目录下）自行新建models文件夹即可，新建的类只要继承模型的基础类即可使用model（ORM），用惯了模型ORM的确实很方便，提供了很多方法，让我们来快速、准确的访问数据库。但是我感到很疑惑为什么laravel 5要把 app/models 删除，是不是在隐式的告诉使用laravel的开发者们放弃使用数据库模型？

我们一直被灌输基于MVC的设计模式开发项目，我相信90%以上的会在app目录下将Models加上，然后为每个数据库表建立对应的模型，然后在控制器中需要用到什么数据模型就 use 引入，每个数据模型同样是可以共用的（控制器之间不要直接互相调用），这是很常规的做法。这样部署没有一点问题，在控制器里直接 use 使用即可。但是 laravel 5 为什么要把 app/models 这个文件夹移除一直想不明白，就在代码编写的过程中，突然想到，我们可不可以为控制器建立模型：

1、controller extends modelcontroller（控制器模型），所有的数据处理和部分逻辑由 modelcontroller 来处理

2、modelcontroller extends bascontroller（控制器基础类）

3、modelcontroller 定义的数据处理模块都是单一可重用的

4、一个控制器模型是可以共用在多个控制器中

5、同样避免控制器间互相调用，use 引入控制器模型即可

6、在控制器模型中引入dao，简化数据库操作

如果像这样去设计你的项目结构，可以想到的好处有：

1、控制器和模型的关系固定：控制器只需要继承对应的控制器模型

2、使用模型便捷：因为控制器和模型是继承关系，不需要use、require等操作，可直接$this指定属性访问

3、清晰的业务结构：控制器继承模型，所有的数据处理都整合在模型中

4、控制器分层

5、高内聚低耦合：一个控制器模型只处理对应控制器的数据，一个控制器模型可以共用多个控制器

6、通过简单的继承关系，业务逻辑和数据处理很容易使用基础类定义的方法

写代码的过程中，突然想到这样的设计去部署代码，会不会更利于我们维护代码，更利于我们开发项目，一个简单的代码设计，可能是个不成熟、没有用处的想法，各路大神有什么高见，在代码设计这一模块，在我们长期被mvc的开发模式所套牢的时代。