大型项目该怎样分层架构，该和MVC说再会了

最近用laravel做本身的小我私人博客，进程中也思索了一些题目，怎样把本身的代码写的更优雅呢，为什么laravel没有models目次呢，逻辑代码，数据库查询代码要奈何安排呢?

我们一向以来都被贯注的计划头脑，即M-V-C，模子(Model)、视图(view)、节制器(Controller)某种水平上是由于Ruby on Rails的风行。Model在大部门开拓者看来就是数据库操纵之类的对象，可是在现实项目开拓的进程中，我们会有大量的逻辑代码，如数据验证，挪用外部处事，发送电子邮件等，以是许多开拓者就将营业逻辑封装到节制器里，当节制器复杂到必然局限，它们将会必要复用其他节制器中的营业逻辑。大部门开拓职员并没有将这些营业逻辑提取到其它的类内里，而是错误的觉得必要在节制器内里挪用其他的节制器要领。这种模式凡是被称为「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 目次下面。这样我们就能很利便的以 QuickBillUser、QuickBillPayment 这种方法来行使它们。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 哀求的统统不该该超出路由和节制器层的范畴。做出好的架构计划简直很有挑衅性，但好的架构计划也会带来可维护的、越发清楚的代码。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!