设为首页 - 加入收藏 邢台站长网 (http://www.0319zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 2018 模式 运营商
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

大型项目该如何分层架构,该和MVC说再见了

发布时间:2019-10-21 03:16 所属栏目:[优化] 来源:Limancheng123
导读:最近用laravel做自己的个人博客,过程中也思考了一些问题,如何把自己的代码写的更优雅呢,为什么laravel没有models目录呢,逻辑代码,数据库查询代码要怎样放置呢? 我们一直以来都被灌输的设计思想,即M-V-C,模型(Model)、视图(view)、控制器(Controller

最近用laravel做自己的个人博客,过程中也思考了一些问题,如何把自己的代码写的更优雅呢,为什么laravel没有models目录呢,逻辑代码,数据库查询代码要怎样放置呢?

大型项目该如何分层架构,该和MVC说再见了

我们一直以来都被灌输的设计思想,即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 命名空间下:

  1. "autoload":?{?
  2. ?"classmap":?[?
  3. ?"database/seeds",?
  4. ?"database/factories"?
  5. ?],?
  6. ?"psr-4":?{?
  7. ?"App\\":?"app/",?
  8. ?"QuickBill\\":?"app/QuickBill"?
  9. ?}?
  10. },?

现在,我们把所有 Eloquent 模型类都放到 QuickBill 目录下面。这样我们就能很方便的以 QuickBill\User、QuickBill\Payment 这种方式来使用它们。Repositories 目录下包含 PaymentRepository 和UserRepository 这种仓库类,仓库类里面包含了所有对数据的访问功能,比如 getRecentPayments 和 getRichestUser。Billing 目录包含了调用第三方支付服务(如 Stripe 和 Balanced)的类和接口。整个目录结构现在应该类似这样:

  1. //?app?
  2. ?//?QuickBill?
  3. ?//?Repositories?
  4. ?->?UserRepository.php?
  5. ?->?PaymentRepository.php?
  6. ?//?Billing?
  7. ?->?BillerInterface.php?
  8. ?->?StripeBiller.php?
  9. ?//?Notifications?
  10. ?->?BillingNotifierInterface.php?
  11. ?->?SmsBillingNotifier.php?
  12. ?User.php?
  13. ?Payment.php?

数据验证放在哪?在哪儿进行数据验证常常困扰着开发人员。可以考虑将数据验证方法写进你的「实体」类里面(例如 User.php 和 Payment.php)。方法名可以设置为 validForCreation 或 hasValidDomain。或者你也可以专门创建一个验证器类 UserValidator,放到 Validation 命名空间下,然后将这个验证器类注入到你的 Repository 类里面。两种方式你都可以试试,看哪个你更喜欢!当然在 Laravel 5.* 中,你不需要自己创建验证器类了,通过 Laravel 自带的验证器类就可以满足你的所有需求。

摆脱了 models 目录的束缚后,你通常就能克服实现好的架构设计的心理障碍,也就能够构建一个更合适应用的目录结构。当然,你构建的每一个应用程序都会有一定的相似之处,因为不管多复杂的应用程序都需要一个数据访问层(Repository),以及一些外部服务层等等。

别害怕目录:不要惧怕创建更多目录来组织管理应用。将整个应用切割成多个细分的功能组件总是必要的,每一个功能组件都专注于某一项职责。跳出「模型」的框框来思考总是有帮助的。例如,我们之前就讨论过,你可以创建一个 Repositories 目录来存放所有的数据访问类。

核心思想就是分层

你可能已经注意到,优化应用目录结构的关键就是对不同组件的责任进行划分,或者说为不同的职责创建不同的层。控制器只负责接收和响应 HTTP 请求,然后调用合适的业务逻辑层的类。你的业务逻辑/领域逻辑层才是应用最核心的部分,其中包含了读取数据,验证数据,执行支付,发送电子邮件,还有程序里所有其他功能的代码。事实上,你的领域逻辑层不需要知道任何关于「Web」的事情!Web 层仅仅是一种访问应用程序的传输机制,关于 Web 和 HTTP 请求的一切不应该超出路由和控制器层的范围。做出好的架构设计的确很有挑战性,但好的架构设计也会带来可维护的、更加清晰的代码。

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章