应用架构
简介
这一章是哪出戏？对于使用框架创建应用这是非常普遍的。很多开发者会提出这样的问题，因为在他们脑仁里已经存在这样的观念，“模型”就是“数据库”。所以通常，控制器被用来和HTTP交互，模型就是和数据库打交道，视图就是还有HTML代码的那部分。但是，对于那些比如发送邮件的类、验证数据类、访问接口的类该怎么区分呢？本章我们就使用Laravel构建好的架构进行探讨，打破那些固话在你心中的概念，让开发回归本质。
阻碍我们的一种设计即：M-V-C。模型，视图，控制器，这种框架思维已经控制开发人员很多年了。这种思维来源于Ruby On Rails。如果，让一个程序员去解释什么是“模型”，通常都会听到将其和“数据库”关联的答案。据说，模型就是数据库。模型包含了数据库的一切。但是，很快你就会发现，在简单的数据库访问类之上还有很多额外的逻辑。他需要我们进行数据验证，调取额外的服务，发送邮件，等等。
什么是模型？
模型现在已经变的模棱两可，很难具体指代什么。根据开发中遇到的那么多词汇，我们可以理解认为，他就是为了将应用切分成小而清晰，具有特定职责的类。
那么，这种困境中的解决方案是什么？很多开发人员会在控制器之上添加更多的逻辑。当控制器变的很大的时候，需要复用其他控制器中的一些逻辑层。很多人会错误的认为需要在当前控制器调用其他控制器，而不是讲逻辑抽象成单独的类。这种模式通常称为“HMVC”。不幸的是，这也是糟糕的设计，通常控制器会很复杂.....

「用Laravel 的中大型项目构架（完结）」