PHP 求使用框架开发的一些经验
看完了Scholer的《现在写 PHP，你应该知道这些》，才清楚开发中，工作使用的框架和自己喜欢的框架时可以区分开的。因为我之前用框架开发，数据库设计，后台，前台，每次一个新项目的开始都要重新做一次数据库设计，网页的页面，开发周期长，老板觉得这样不好，说需要开发一个CMS，提高程序的重用性。目前选择框架时，我担心的是:
客人的服务器版本可能还是使用5.3.x版本
假如客人服务器版本是PHP5.3.X，用yii2或者Laravel 4.2 开发的项目，在客人的服务器中不能使用
目前我在Yii2和Laravel 4.2这两个框架之间徘徊，因为这两个要求的PHP版本都是5.4 或者之上，所以我自己不敢实打实的去学习其中的一个框架。Thinkphp目前考虑以后不再使用，因为这是我目前使用的，只是想跳出TP。
因为我目前只清楚数据库的RBAC,USER表的设计，后台的RBAC是可以重用的，相应的功能，我要根据项目的实际功能进行重新code一次。
希望有朋友可以告诉我一些开发的建议，在使用框架时，我应如何提高程序的重用性，避免一个新的项目开始，数据库设计，后台，前台都减少相应的重复操作。
第一次提问，废话有点多，还请你不吝赐教。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
怎么说呢…… 其实当时写这个 是跟一个朋友讨论问题，他问我能不能把一些东西组件化、热拔插这种，我说可以啊…… 试试composer…… 很偶然很偶然，我弄这么个标题纯属无意……但是这种标题似乎都带有些爆炸性……
其实我的初衷是想说明一件事情：PHP 在变化，可以选择的也多，不要还拿 wordpress、或者某些基于 PHP4 时代的框架的眼光来看待。
之前很多人都看过 phptherightway，也有人翻译过《Modern PHP》这本书，其实我的观点和作者是一致的：PHP 在变化，从事这一行，是否你也考虑一下改变自己？
就像我们以前常用 PHPMailer 来发邮件，现在 很多框架里集成的 却是 swiftmailer。如果你用过 Laravel，不防研究一下 vendor 下的每个依赖项目？每个依赖项目的作者还做过什么别的有意思的东西？
当然我这么讲，也是因为我自己也会搞搞服务器上的事情，所以一直也不在乎客户提供什么，因为这些我都可控，在乎的都是我想要做什么。
我想做什么，这也是我选择什么、喜欢什么的原因。这是一份工作，但不仅仅是完成任务，我可以有自己的喜好，自己的选择，也能从中获得乐趣。所以我倾向于多了解，选择最合适的。这个『合适』包括项目成熟度、易用程度、学习成本、维护周期等等。
上面这些是在扯背景，再说下你的问题吧。
重用
composer 无疑就是重用和借助开源的力量简化一些繁复的工作的手段。这个理念跟 pip、npm 没什么分别。只是概念提出来的比较晚（大概 11年 还是 12 年？），所以现在还没那么高的知名度。开发一些组件，放到公有和私有仓库，composer 和 psr4 帮你解决加载的问题，这不是很好的重用吗？
框架选择
laravel 和 yii2 本质上有很多相同，但是设计理念上缺又有非常大的不同，你也可以看看别的一些框架，symfony，phalcon 等等。接触一个新的东西总是会遇到挑战的，有成本的，主要还是考虑项目类型（是页面为主还是 API？和前端的配合等等），怎么选择？看收益。如果你看不懂长远的收益，没法做出选择的。
数据库设计
数据库设计其实本身是个和 PHP 和框架都无关的问题。如果说扯上关系，不防从两个方面来想：
预置的数据表/数据关系
ORM 或者 Model 操作方式
这个问题讲大了可以扯到设计理念、代码组织方式之类的，扯小一点就是：能不能快速上手。
实际开发中，哪怕是设计一个登录注册的模块，对于某些开发人员来说可能都要很久（有的人也许擅长实现、但并不擅长设计）。所以选择一些预置了某些基本数据关系的框架可能会容易一点。
至于 ORM 和 Model 这一块，简单的例子，Eloquent 的操作方式和 CodeIgniter 肯定是不同的。光是概念都有很多：Active Record、data mapper、DAO（创造概念来描述自己的想法这件事情产生的自豪感也许比内容本身更大）。你要么不用框架，要么造个轮子，要么乖乖的按照框架的思维模式来，因为框架总免不了有一堆集成工具的组合（或者说是最佳实践）。
后台、前台
这个问题其实和前面一段差不多，你大概知道 yii2 有一个什么 advanced 版本，帮你分一下 frontend、backend 之类的。这个事情做起来困难吗？不困难。但重要的是什么？一个概念、或者叫一个设计吧，还是那句话：有些开发人员擅长实现，但并不擅长设计。后台前台的分离，是搭两套框架，还是一套框架里套两个不同的 app 目录，还是自己设计一个基于 URI 或者域名区分的，事情的本身并不重要。重要的是实现成本。
其实讲了这么多，我想表述的是什么呢？就是要有自己的『观点』、『调研』、『喜好』。然后能尝试动手『实践』。工程师不是机器，有自己的喜好才是正常。喜好和工作并不冲突，就像业务和技术并不冲突一样。想办法把自己的想法和喜好付诸实践，用技术带动业务才是吾辈应该做的事情。
再多扯一点。
PHP 不像前端，现在搞得貌似是蓬勃生机，欣欣向荣，有那么多流派。但 PHP 也并没有沉沦，也一直都有传统观点：能干活就行，现代一点的观点：Composer、PSR，甚至像 symfony 路由都已经写到注释里去了，再高端一点的：C 扩展，PHP 是个架子（此类大神也许对前面的多有不屑）。这本身也是多样化、灵活性的一种表现。
PHP 不是最好的语言，甚至谈不上是好的语言，但好在无数业界前辈（比如鸟哥，比如 nikic，PHP 核心开发，也创造了 FastRoute、PHP-Parser 这些优秀的组件）正努力让它变好，尝试他们的劳动成果也是一种贡献，也许最终你我都会是受益者。
为啥不再使用Thinkphp,想跳出tp 给后面掉坑的人也指条明路
OneThink不就是基于ThinkPHP现成的后台吗?第三方的还有ThinkCMFX, CoreThink, ShuipFCMS这些.
我觉得你这两个担心完全时多余的，你大可正常使用这两个框架开发，如果部署时真是客户的 PHP 只能时 5.3 的，大不了你根据出现的问题，修改这些框架的源码（都是开源的，没有后顾之忧），进行 5.3 的适配即可。5.3 到 5.4 的改动并不算多，轻轻松松可以完成适配。
另外：
ThinkPHP确实存在一些弊端，你早点离开并不是件坏事。我认为ThinkPHP最大的隐患就是没有支持Psr4的规则，导致基本很难引入体系外的第三方库。这也就是框架之间程序很难复用的原因。