这个类要放到哪儿？这可能是基于框架构建运用时非常常见的问题。很多开拓者都会有这个疑问，由于他们被贯注灌注了「模型」便是「数据库」这种观点。因此，在掌握器里面处理 HTTP 要求，在模型类里面操作数据库增编削查，在视图里编写要显示的HTML，成了开拓者们约定俗成的规定。但是，发送电子邮件的类要放到哪儿？验证数据的类呢？调用外部 API 的类呢？在这一章中，我们将先容 Laravel 框架中良好的运用构造，并冲破那些常见的阻挡开拓者做出好设计的生理障碍。
MVC是慢性行刺
阻挡开拓者做出好设计的最大拦路虎便是一个大略的首字母缩写词：M-V-C。模型（Model）、视图（View）、掌握器（Controller）已经统治 Web 框架的设计思想好多年了。这种思想的泛滥某种程度上由于 Ruby on Rails 的盛行。然而，如果你问一个开拓者「模型」的定义是什么，常日，你会听到他嘟哝着什么「数据库」之类的东西。这么说，模型便是数据库了。不管这意味着什么，模型里包含了关于数据库的统统。但是，你很快就会知道，你的运用程序须要的不仅仅是一个大略的数据库访问类。它须要更多的逻辑，如数据验证、调用外部做事、发送电子邮件等等。
模型」这个单词的含义太模糊了，以至于显得没有任何意义。更详细来讲，模型是用来将我们的运用划分成更小、更清晰的类，使得各代码部分有着明确的权责。
以是，怎么办理这个问题呢？很多开拓者开始将业务逻辑封装到掌握器里面。当掌握器弘大到一定规模，它们将会须要复用其他掌握器中的业务逻辑。大部分开拓职员并没有将这些业务逻辑提取到其余的类里面，而是缺点的以为须要在掌握器里面调用其他的掌握器方法。这种模式常日被称为「HMVC」。遗憾的是，这种模式常日也意味着糟糕的程序设计，以及掌握器太过繁芜。
HMVC 意味着糟糕的设计：你以为须要在掌握器里面调用其他的掌握器？这常日意味着糟糕的程序设计，以及你的掌握器里面包含了过多的业务逻辑。好的做法是把掌握器中的业务逻辑提取出来，放到一个新的第三方类里面，常日，我们将这种第三方类称之为做事类，这样你就可以在所有其他掌握器里面注入做事类并利用它们了。
有一种更好的办法来构建运用程序构造。但首先我们要忘掉以往我们被贯注灌注的关于「模型」的统统。干脆点，让我们直接删掉模型目录，重新开始吧！
再见，模型
删掉你的 models 目录了吗？还没删就赶紧删了！
我们将要在 app 目录下创建一个新的目录，目录名就以我们这个运用的名字来命名，比如 QuickBill。我们将连续利用在前面章节中编写的那些接口和类。
把稳利用场景：记住，如果你在构建一个很小的 Laravel 运用，那在models 目录下写几个 Eloquent 模型实在挺得当的。但在本章节，我们紧张关注如何开拓适用于分层架构的大型繁芜项目。
以是，我们现在有了个 app/QuickBill 目录，它和运用目录下的其他目录如 Http 还有 Console 都是平级的。在 QuickBill 目录下我们还可以创建几个其他目录，例如 Repositories 和 Billing 目录。目录都创建好往后，别忘了在 composer.json 文件里通过 PSR-4 自动载入机制将它们注册到 QuickBill 命名空间下：
\"大众autoload\公众: { \公众classmap\"大众: [ \公众database/seeds\"大众, \"大众database/factories\"大众 ], \"大众psr-4\"大众: { \"大众App\\\"大众: \公众app/\"大众, \"大众QuickBill\\\"大众: \公众app/QuickBill\"大众 }},
现在，我们把所有 Eloquent 模型类都放到 QuickBill 目录下面。这样我们就能很方便的以 QuickBill\User、QuickBill\Payment 这种办法来利用它们。Repositories 目录下包含 PaymentRepository 和UserRepository 这种仓库类，仓库类里面包含了所有对数据的访问功能，比如 getRecentPayments 和 getRichestUser。Billing 目录包含了调用第三方支付做事（如 Stripe 和 Balanced）的类和接口。全体目录构造现在该当类似这样：
// app // QuickBill // Repositories -> UserRepository.php -> PaymentRepository.php // Billing -> BillerInterface.php -> StripeBiller.php // Notifications -> BillingNotifierInterface.php -> SmsBillingNotifier.php User.php Payment.php
数据验证放在哪？在哪儿进行数据验证常常困扰着开拓职员。可以考虑将数据验证方法写进你的「实体」类里面（例如 User.php 和 Payment.php）。方法名可以设置为 validForCreation 或 hasValidDomain。或者你也可以专门创建一个验证器类 UserValidator，放到 Validation 命名空间下，然后将这个验证器类注入到你的 Repository 类里面。两种办法你都可以试试，看哪个你更喜好！
当然在 Laravel 5. 中，你不须要自己创建验证器类了，通过 Laravel 自带的验证器类就可以知足你的所有需求。
摆脱了 models 目录的束缚后，你常日就能战胜实现好的架构设计的生理障碍，也就能够构建一个更得当运用的目录构造。当然，你构建的每一个运用程序都会有一定的相似之处，由于不管多繁芜的运用程序都须要一个数据访问层（Repository），以及一些外部做事层等等。
别害怕目录：不要畏惧创建更多目录来组织管理运用。将全体运用切割成多个细分的功能组件总是必要的，每一个功能组件都专注于某一项职责。跳出「模型」的框框来思考总是有帮助的。例如，我们之前就谈论过，你可以创建一个 Repositories 目录来存放所有的数据访问类。
核心思想便是分层
你可能已经把稳到，优化运用目录构造的关键便是对不同组件的任务进行划分，或者说为不同的职责创建不同的层。掌握器只卖力吸收和相应 HTTP 要求，然后调用得当的业务逻辑层的类。你的业务逻辑/领域逻辑层才是运用最核心的部分，个中包含了读取数据，验证数据，实行支付，发送电子邮件，还有程序里所有其他功能的代码。事实上，你的领域逻辑层不须要知道任何关于「Web」的事情！
Web 层仅仅是一种访问运用程序的传输机制，关于 Web 和 HTTP 要求的统统不应该超出路由和掌握器层的范围。做出好的架构设计的确很有寻衅性，但好的架构设计也会带来可掩护的、更加清晰的代码。
举个例子，与其在业务逻辑类里面直接获取 Web 要求，不如把 Web 要求通过掌握器通报给业务逻辑类。这个大略的改动会将你的业务逻辑类和「Web」层解耦，并且不必担心怎么去仿照 Web 要求，就可以轻松测试业务逻辑类：
class BillingController extends BaseController{ public function __construct(BillerInterface $biller) { $this->biller = $biller; } public function postCharge(Request $request) { $this->biller->chargeAccount(Auth::user(), $request->input('amount')); return view('charge.success'); }}
现在 chargeAccount 方法更随意马虎测试了，由于我们不再须要在 BillerInterface 实现类中利用 User 和 Request类，只需将用户和金额通报到该方法即可。
编写可掩护性运用程序的关键之一，便是职责分离。要时常检讨一个类是否管得太宽，知道一些它不该知道的。你要常常问自己「这个类是否须要关心X？」如果答案是否定的，那么就要把这块逻辑提取出来放到另一个类里面，然后用依赖注入的办法将其注入进来。
如何判断一个类是否管得太宽？一个有用的方法便是检讨你为什么要改这块代码。举个例子，当我们想调度关照逻辑的时候，是否须要修正 Biller 的实当代码？当然不须要，Biller 实现只关注支付，它与关照逻辑应该仅通过左券来进行交互。在处理代码时利用这种思路，可以帮助你快速找出运用中须要改进的地方。
东西都放哪儿？
当通过 Laravel 开拓运用时，你可能会困惑于该当把各种「东西」放在哪里。例如，赞助函数要放在哪里？事宜监听器要放在哪里？视图组件要放在哪里？答案可能出乎你的猜想 —— 「随便，放哪儿都行！
」Laravel 并没有很多关于这方面的文件系统上的约定。不过，这个答案的确不能让人满意，以是下面我们就这个问题展开谈论，一起磋商这些「东西」究竟可以放在哪里。
赞助函数
我们可以在 app 目录下创建一个 helpers.php 文件，然后将自定义的赞助函数都放到这个文件中。当然，由于这个文件里面包含的不是类，不适宜通过命名空间引用个中的函数，须要在 composer.json 中全局注册它：
\"大众autoload\"大众: { ... \"大众files\"大众: [ \"大众app/helpers.php\"大众 ]},
然后运行 composer dump-auto 重新注册自动加载映射关系。然后就可以在运用中利用 app/helpers.php 中定义的赞助函数了。
事宜监听器
事宜监听器当然不该放到 routes.php 文件里面，以是我们要找其余的地方来存放。事实上，在 Laravel 5. 中，当我们通过 php artisan make:listener 命令创建韶光监听器时，系统会自动在 app 目录下创建 Listeners 子目录，并将天生的监听器类放到该目录下。以是我们对付自定义的事宜监听器类，放到该目录下即可。
缺点处理器
在 Laravel 5. 版本中，默认情形下所有的非常都是通过 App\Exceptions\Handler 来处理的，你也可以通过自定义的非常类来处理，自定义非常类可以放到 app/Exceptions 目录下。
其他
常日，只要遵照 PSR-4 规范就可以在运用目录构造中保持类的整洁。结合你目前为止学习到的知识，对付什么代码要放在什么地方这个问题，应该可以给出一个有理有据的答案了。但永久不要谢绝试验。Laravel 的美妙之处便是你可以做出最适宜你自己运用的约定。去探索和创造最适宜你自己运用的构造吧，别忘了和他人分享你的见地！
例如，你可能受到我们之前例子的启示，在 QuickBill 中创建一个 Providers 目录来存放所有你自定义的做事供应者，目录构造类似这样：
// app // QuickBill // Billing // Extensions //Pagination -> Environment.php // Providers -> EventPusherServiceProvider.php // Repositories User.php Payment.php
把稳上面的例子，我们有 Providers 和 Extensions 两个命名空间。所有你自定义的做事供应者都可以放到 Providers 命名空间下，而 Extensions 命名空间可以用来存放你对框架核心进行扩展的类。
如果你现在在口试PHP的道路上，看看口试根本题吧
举两个例子，怎么样写好代码
最经典的算法，献给正在口试道路上的你
