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

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

桃知夭夭
本帖已被设为精华帖!
本帖由 Summer 于 6年前 加精
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《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年前 评论

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