Laraval 有非常多且优秀的扩展,那么新手应该如何去挑选适合自己项目的扩展??

Laraval有非常多且优秀的扩展,那么新手应该如何去挑选适合自己项目的扩展??
教程里面作者引用了很多扩展来提高开发效率,新手在开发项目中如何去选择和业务逻辑统一的扩展?

桃知夭夭
本帖已被设为精华帖!
本帖由 Summer 于 6年前 加精
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
leo
最佳答案

个人不太喜欢引入过多的 package

  1. 很简单功能的 package,比如 为你的 Laravel 模型增加分享功能 ,因为功能实在太简单,我自己写可能只要10分钟就能搞定,找扩展、学习扩展的用法可能就要花几个小时,不划算,还有可能这个扩展在未来可能并不能满足你的需求,或者是没有支持新版本的 Laravel,你要去改动要么是 fork 之后自己发一个 composer 包,要么是提 issue 等作者更新。
  2. 涉及前端代码的 package,比如 Laravel-Administrator。近几年前端开发发展迅猛,webpack 等前端构建工具已经非常成熟,像 Laravel-Administrator 这种还把前端类库放在代码库里的 package,我是绝对不能接受的。另外就是界面风格基本上锁死,否则 summer 也不会自己 fork 一个来优化 UI 了。

我通常引入的 package 有这么些特征:

  1. 通用类库,比如 jwt 、predis
  2. 非常复杂的功能,比如 oauth(即 Laravel 的 passport)
  3. 各种 sdk,比如 easywechat
  4. 辅助开发的包,如 laravel-ide-helper、tinker

另外我不会特地去使用那些专门为 Laravel 封装的 package,比如 laravel-wechat,我宁愿使用 easywechat,原因如下:

  1. 这些 package 通常会注册一些 Facade。而我个人认为除了 Laravel 自带的 Facade,其他 Facade 会带来额外的不必要的学习成本和 debug 成本,特别是在多人合作的情况下。
  2. 这些 package 通常会生成一个 config 文件。当这种 package 非常多的时候,config 目录下文件会非常多,要找某个配置可能得仔细翻半天。

以上都是我个人对引入 package 的观点,请根据自己项目的实际情况参考。

6年前 评论
讨论数量: 6
leo

个人不太喜欢引入过多的 package

  1. 很简单功能的 package,比如 为你的 Laravel 模型增加分享功能 ,因为功能实在太简单,我自己写可能只要10分钟就能搞定,找扩展、学习扩展的用法可能就要花几个小时,不划算,还有可能这个扩展在未来可能并不能满足你的需求,或者是没有支持新版本的 Laravel,你要去改动要么是 fork 之后自己发一个 composer 包,要么是提 issue 等作者更新。
  2. 涉及前端代码的 package,比如 Laravel-Administrator。近几年前端开发发展迅猛,webpack 等前端构建工具已经非常成熟,像 Laravel-Administrator 这种还把前端类库放在代码库里的 package,我是绝对不能接受的。另外就是界面风格基本上锁死,否则 summer 也不会自己 fork 一个来优化 UI 了。

我通常引入的 package 有这么些特征:

  1. 通用类库,比如 jwt 、predis
  2. 非常复杂的功能,比如 oauth(即 Laravel 的 passport)
  3. 各种 sdk,比如 easywechat
  4. 辅助开发的包,如 laravel-ide-helper、tinker

另外我不会特地去使用那些专门为 Laravel 封装的 package,比如 laravel-wechat,我宁愿使用 easywechat,原因如下:

  1. 这些 package 通常会注册一些 Facade。而我个人认为除了 Laravel 自带的 Facade,其他 Facade 会带来额外的不必要的学习成本和 debug 成本,特别是在多人合作的情况下。
  2. 这些 package 通常会生成一个 config 文件。当这种 package 非常多的时候,config 目录下文件会非常多,要找某个配置可能得仔细翻半天。

以上都是我个人对引入 package 的观点,请根据自己项目的实际情况参考。

6年前 评论

@ibucoin 正确的描述应该是写代码为乐趣 :laughing:

6年前 评论
leo

个人不太喜欢引入过多的 package

  1. 很简单功能的 package,比如 为你的 Laravel 模型增加分享功能 ,因为功能实在太简单,我自己写可能只要10分钟就能搞定,找扩展、学习扩展的用法可能就要花几个小时,不划算,还有可能这个扩展在未来可能并不能满足你的需求,或者是没有支持新版本的 Laravel,你要去改动要么是 fork 之后自己发一个 composer 包,要么是提 issue 等作者更新。
  2. 涉及前端代码的 package,比如 Laravel-Administrator。近几年前端开发发展迅猛,webpack 等前端构建工具已经非常成熟,像 Laravel-Administrator 这种还把前端类库放在代码库里的 package,我是绝对不能接受的。另外就是界面风格基本上锁死,否则 summer 也不会自己 fork 一个来优化 UI 了。

我通常引入的 package 有这么些特征:

  1. 通用类库,比如 jwt 、predis
  2. 非常复杂的功能,比如 oauth(即 Laravel 的 passport)
  3. 各种 sdk,比如 easywechat
  4. 辅助开发的包,如 laravel-ide-helper、tinker

另外我不会特地去使用那些专门为 Laravel 封装的 package,比如 laravel-wechat,我宁愿使用 easywechat,原因如下:

  1. 这些 package 通常会注册一些 Facade。而我个人认为除了 Laravel 自带的 Facade,其他 Facade 会带来额外的不必要的学习成本和 debug 成本,特别是在多人合作的情况下。
  2. 这些 package 通常会生成一个 config 文件。当这种 package 非常多的时候,config 目录下文件会非常多,要找某个配置可能得仔细翻半天。

以上都是我个人对引入 package 的观点,请根据自己项目的实际情况参考。

6年前 评论
ibucoin

@leo 想到了以写插件为乐趣的@overtrue 大神。

6年前 评论

@leo 原来如此哈哈 。学到了,thank you ~~

6年前 评论

@ibucoin 正确的描述应该是写代码为乐趣 :laughing:

6年前 评论

优秀的作者维护勤劳的 package 还是要多用,特别是非简单的功能,像管理员所说的 Facade Config, Facade 可以删除,而且 Facade 基本不需要深入了解,只要会用简单了解即可, Config问题比如:config 目录下建个自下载 package 放置目录 selfConfig,再把 package 稍做修改,同时学习优秀的 package 代码,相信就算那一天,有个别包作者不再维护升级,到时自个也能把包升级。刚开始可能会需要多花点时间了解 package 包,实战多民,后面的 package 自然顺。 以上为个人观点

5年前 评论

能解决眼前问题的包,就使用 :smile:

3年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!