时间：2021-07-01 10:21:17 帮助过：19人阅读
这个问题已被关闭，原因：非技术提问的讨论型问题
如题，苦恼啊！
我该怎么办呢？
求有经验的前辈大哥给点指点！
谢谢！
没有接受 laravel 的理念。
另一方面，laravel 的门槛确实比普通框架高。
我们学一门技术，不是因为他简单，而是因为他强大。
完全看不懂
这比较难回答了，太笼统了。
先写个 hello world 吧。
懂了。第一步迈出去了。
再写个 hello name 吧。
hello tom
hello jerry
hello zhangsan
hello hanmeimei
懂了，知道怎么传递 GET 参数了，控制器啊，路由啊，什么什么的。。。。
再写个小页面吧，页面里输出 hello name。
又懂了，View 懂了。
再写吧，把 name 放到数据库。ORM也懂了。
。。。。
just do it
just do it
just do it
看Laravel就像在看文章一样，所见即所得，条理非常清晰。你看不懂，可能是应为你不熟悉OOP，或者MVC，或者看的时间太短。看文档不能只看代码部分，说明部分也很重要，名词解释，结构说明往往都在大段文字的部分。
P.S. 很久以前看过wordpress的代码，感觉就是历史的遗物，在当时WP那个年代，这种简单粗暴的CMS项目容易上手，加上生态圈渐渐庞大，一句代码不懂的人，会点css，html的人都能靠插件搞CMS站了。但是今天如果你理解不了依赖注入，事件驱动，自动测试，模块化组件，MVC带来的好处，还在念着wordpress，discuz的好，那只能希望你继续用wordpress，discuz了。
>
<?php bloginfo('name'); ?> › <?php echo $title; ?>
像上面那种代码，确实简单易懂，（wordpress源码），但是可能不够优雅，更别提源码中这些_SERVER数组，例如$http_post = ('POST' == $_SERVER['REQUEST_METHOD']);。
拥抱变化，拥抱不同的思想，有些框架并不仅仅是PHP基础函数的一点封装。
和大部分框架做的一样，laravel无非是路由器+视图+控制器+模型，只不过laravel封装的比较狠，一个->withName和一个->withNames直接能在下一个页面创建一个名叫name的和一个名叫names的变量：原来PHP也能这样玩。
在深入下去，会发现laravel居然也搞依赖注入，类，完全和其他的语言一样。
不要总是徘徊不前。
其他：
框架之争关我毛事，让用什么用什么……
我要写Go。
补充两点：
非得说名人名言的话：思想自由，兼容并包---蔡元培。
我对PHP框架没什么歧视，唯独偏爱YII。但是我觉得laravel完全可以看成是一门新的、兼容PHP的语言。每个框架都能看成一门语言，其实更清楚点说，应该是每个框架都有其背后的思想。
拥抱改变。
没工作的时候，代码再优雅并没有什么用。有工作的时候，代码优雅能当加餐吃。
laravel的官方文档其实并不怎么全，看上去很全，有很多东西没有写出来。这个时候，零散的知识点查谷歌最好，百度也搜到部分相关的成体系的文章：两个一定都要用。
mysqli不要再用了……
用一下PDO+prepared statement……
laravel有非常好的查询方法（详见查询构造器）和Eloquent……
这么多年技术一直在变化，唯一不变化的就是变化本身。
你把C++当成C with class来用，倒也没什么，
但是把C++当成C来面向过程就有点。
PHP的高级用法并不是无缘无故加上去的，也不是让它在角落里吃灰的。
PHP已经提供了类，面向对象，甚至闭包函数、lambda函数（PHP5.3），
再死守着面向过程的那一套反而是食古不化。
可能因为英文本来就不是我们的母语所以好处没有那么深 但是你用久了 laravel 你会发现所有的设定都是想办法让代码读起来像一句话
我觉得你不要看中文文档先 认认真真过两遍英文文档然后看看laracasts的 l5 基础 那个系列
看laravel开始不明白很正常 没人能0基础在一个小时内看完 你弄明白wordpress也要有几天甚至几个月呢不是么
最重要的是
never stop learning
首先，我还是一个PHP的入门者，我反到觉得Laravel这样的特别适合我个人的思维和想法。至于文档为什么会看不懂，具体原因我并不知道，但是我个人认为一个像Laravel这样的框架，你首先需要弄明白的是MVC这个三个部分，这三个部分的工作流程和担任的角色分清楚了，然后再看看ORM，基本上你的框架入门基础就有了。
你的问题在于没怎么深入了解过框架，对于一个多年的phper来说，你落后很多了
用PHP好几年了，不知道为什么很多要使用laravel，类都是深度封装，严重影响其性能，团队中大家的水平也不一样，用laravel写出来的代码，可读性真的是屎一样的，除了抛异常比较友好外，我觉得没有什么特点，laravel之前在公司内部被大力推荐，我们花了一年多的时间将其迁移到yaf，选择PHP框架很简单，只能路由分发，其他扩展使用公司composer管理。
@eechen @atekul @justjavac 的答案都挺好的，都说明了框架不是开发一个网站的必要，框架可能只是为了让你更好的组织你的代码而已。我们写的代码可能没有一个优秀的框架那么优雅而已，但当你一旦适应了那么一种套路之后，你即使不用框架也能够写出结构组织优美，易于维护的代码。正如 @justjavac 说的，just do it ，从hello world开始，一步步看他如何做路由，如果做存储，如何做缓存，如何做加密等等。仅仅看文档是不够了，写一段代码，调试跟踪，或许会更加快的把握它的路径。
https://laravist.com
来这里看基础吧，大家一起学，我也刚刚学
php本身就是一个框架，真正的php的最高境界就是无框架，即使你需要框架，也要自己写框架，自己写出来的框架才是世界上最好的框架
框架的作用是减少代码量，并且让软件变得有组织结构。
也就是说，框架在一定程度上封装了许多开发中常见的操作，并且可能做了更多扩展。
当然，你也可以在框架中使用$_GET取参数，虽然提高了效率，但是这样的话就无法从框架中获益。
用好一个框架必须要有全局的意识，还有不断的学习和总结。
laravel最大的优点是它的依赖注入吗？ 我觉得不是，追溯到laravel的爆发，composer也在爆发， laravel是依托于composer的，它的artisan工具可以执行某些支持laravel包里面的migrate操作就是一个很好的例证, 贡献特殊的包（指有些模块需要操作数据库，有个典型的是用户权限验证组件https://github.com/Zizaco/entrust，为laravel设计）或者普通的包给laravel都是很方便的一件事。自己编写的包，以包这样的小集体为单位做开发，用git单独为包标识version，如果每次都是文件到另一个项目那就太蠢了吧。包也可以贡献给社区，为开源做贡献， 毕竟开发的力量大部分来源于社区。
laravel它对composer的包友好，对测试友好（举例：本地开发可以根据环境启动应用，加载不同的配置，自带的有测试hepler类，并且很多测试框架都对laravel支持很好）， 对ci友好（举例：以migrate作为数据的基础，使用mysql的程序可以用sqlite做测试，migration做了统一的接口），对git友好（举例：无用的缓存文件都归纳到一个到或者两个文件夹;.env的文件配置方式，一个配置搞定所有;vendor文件夹不用托管，composer.lock都描述了）， 拥有这些可以建立起一条适用于现代的开发流程。程序员使用这个框架是从团队协作出发，从自动化出发, 从易于分享出发，laravel的架构都解决了这些问题。
laravel是不是最佳实践？ 我也无法回答。但是我可以肯定的是它是符合现代开发流程的。
优雅不优雅不说，谁能告诉我，用composer安装了几个过度封装的包（包括阿里云的oss sdk及其他）,xhprof打出来的堆栈几乎让我想哭，一个业务逻辑在xhprof采样后，转出来的dot文件有3k+行，用dot渲染成jpg要花十分钟…………
我就只想简简单单的支持业务，优雅爬开。
我们学习PHP,不仅是因为它强大,更是因为它简单.
PHP的成功,不是因为那些框架,而是WordPress这些新手都能搭起来的应用.
所以,别被那些整天鼓吹XXX框架的拥趸给蛊惑了.
就拿一个文章页实现来说:
/post.php //页面控制器(处理输入,调用模型,像这种一目了然的代码结构,想不看懂都难,而且一样能分离界面跟逻辑,实现MVC.
前端控制器(路由)并不是实现MVC必需的设计模式.
MVC的核心思想是分离界面(View),逻辑(Controller),数据(Model).
比如浏览器访问页面控制器,控制器处理输入,调用模型获取数据,载入视图输出数据.
PHP几句代码就能轻松实现MVC:
/post.php?id=1024 //页面控制器(输入ID,PHP自身提供的那么多超全局变量,是给用户用的,不是给框架封装的.
大多数函数都依赖数据库连接,PHP的话完全可以在函数内用global $mysqli,
从而拿到全局的MySQL连接对象进行CRUD操作,简单直观.
为什么一定要用依赖注入?搞那么复杂干什么.
很多人都觉得全局变量没有OOP的依赖注入那么优雅,但优雅能当饭吃吗?
为了优雅,是不是连PHP提供的超全局变量也不用了?简单直观才是PHP的王道.
比如按需动态生成全局的数据库连接对象:
'db_conn_obj');
// functions.php
function cn_db(&$app) {
$app['db_conn'] = @new mysqli('127.0.0.1', 'root', 'pass', 'mysql');
register_shutdown_function(function() use ($app) { $app['db_conn']->close(); });
}
function cn_foo1() {
global $app;
if(!is_object($app['db_conn'])) cn_db($app);
return $app['db_conn']->query('select user,host from user where user = \'root\'')->fetch_all();
}
function cn_foo2() {
global $app;
if(!is_object($app['db_conn'])) cn_db($app);
return $app['db_conn']->query('select user,host from user')->fetch_all();
}
// controller
print_r(cn_foo1());
print_r(cn_foo2());框架的前端控制器,不仅增加了Nginx服务器的重写负担,也增加了PHP处理的负担.
可以用独立的可通过URL直接访问的页面控制器(Page Controller)代替前端控制器(Front Controller)的路由功能.
可以用common.php代替前端控制器执行一些公共操作,加载公共库.
可以用超全局变量代替框架URL分析获取GET/POST参数.
可以用PHP自带的模板引擎取代第三方模板引擎(Smarty,Twig).
别忘了,PHP本身就被设计成一个Web工具箱,框架不应该再重新造轮子.
转:
首先,前端控制器里存在一个路由转发的过程,这个过程是在服务端完成的,
不管是什么请求都要经由前端控制再完成路由转发,这个过程很可能会引起性能问题.
如果抛弃了前端控制器的做法,转而使用页面控制器的实现方式,那么服务端就不必再存在路由转发的过程,
因为在把页面渲染到浏览器上的时候,自然而然就完成了路由的设定,不同的动作对应着不同的URL.
功能实现则完全由页面控制器来实现.如果某个动作引起了性能的瓶颈,那么我们只要针对这个动作对应的URL增加更多的服务器就可以完成扩展.
另外,传统的MVC理论里,强调代码逻辑上的分离,但并未就物理分离做出描述,Rasmus Lerdorf在这方面做出了有益的补充.按Rasmus Lerdorf的引申想法,M和V是分别位于不同服务器的,V通过WebService调用M上的数据.请牢记Rasmus Lerdorf的教诲.
https://msdn.microsoft.com/zh-cn/library/ms978723.aspx
Front Controller 比 Page Controller 更复杂，实现此解决方案会增加维护成本和新手的学习难度。
Front Controller 是用来处理 Web 应用程序的所有请求的单个控制器。
如果处理程序必须执行数据库查询或 XML 文档查询才能作出路由决定，则可能导致性能非常缓慢。
Page Controller 模式是 Front Controller 的更简单替代方案。
在 Page Controller 模式中，每个页面各有一个控制器对象，这与所有请求使用一个对象的 Front Controller 方案相反。对于大多数应用程序来说，Page Controller 是更合适的起点。仅当需要 Front Controller 时才应该使用它。
SSDB 作者对于 PHP 框架的一些要求:
http://www.ideawu.net/blog/archives/828.html
1.不能做太多事
PHP 框架不要总想做所有事, 缓存系统不需要框架来做, Session 管理也不需要,
存储层封装不要太过度以至搞出各种恶心的 ORM, Active Record 之类的无用功能.
这些功能和模块, 应该独立于框架, 采用成熟的技术.
2.不要"创造"所谓的模板语言
PHP 语言本身就是模板语言, PHP 做模板语言对于 PHP Web 来说是最完美的, 可维护性和培训成本最佳的语言,
只需要再多说一两句话规范即可: 仅使用 echo 及允许的帮助 echo 的函数, 和 if/for/while.
我十年前不认同 smarty 这类模板工具的意义, 十年后也不认可这类毫无意义的寄生于 PHP 的工具.
3.使用 PHP 框架的最佳状态是忘掉框架
框架要足够简便, 功能恰到好处, 没有不必要的限制, 这样在使用的过程中才能让人忘掉框架的存在, 以便能将精力放在业务本身.
当需要开发一个功能时, 程序员想的不应该是"框架能不能做", 而是"我能不能做".
4.最后
我自己也开发了一个轻量级的 PHP 框架, 命名为 iphp. iphp 非常简便和轻量, 全部有效代码不过一千行.
iphp 只解决 Web 开发中最重要的问题: 代码组织, URL路由和URL生成.
Swoole作者韩天峰:
用PHP开发一套网站程序,用不用框架都无所谓.其实关键是,要有合理的程序结构规划,高度重用性,低耦合度.
1.一定要避免复制粘贴.
在多个地方重用的功能,封装成函数(最好用不同的前缀表明是什么系列的),或者类(类更好一些).
不仅是PHP代码,包括模板文件,也要封装成block.这样的话,一旦有需要增加,改动,只修改一个地方就可以了,无需到处改.这样也更方便写单元测试,来检测你程序的错误,进行压力测试,保证模块的性能.
2.要注意规划你的程序.
不要埋头写程序,先做规划,心目中有构想,形成一个系统,然后再实施.
3.不要用一段大而长的代码解决一个问题,或者用一个非常多参数的函数,非常多方法的类去实现一个问题.
要分层解耦,一个模块只做,且做好一个事情就可以了.
为什么我说ORM是一种反模式
http://www.nowamagic.net/librarys/veda/detail/2217
ORM最初比编写基于SQL的模型代码更快,也更容易理解,在任何项目早期都是足够有效的.
不幸的是,这些优点在项目复杂性提升的时候就消失了:抽象被打破,开发者被迫使用并理解SQL.
完全是非正式的声明,我认为ORM对抽象的破坏不是仅仅涉及20%的项目,而是几乎100%.
对象并不足以充分表达关系查询的结果.
关系查询映射到对象的不充分性导致了ORM后端应用的效率低下,这些问题普遍分布在应用的各处,并且除了完全放弃ORM之外,没有简单的解决办法.
不要对任何问题都使用关系存储与ORM,而是更加仔细地思考你的设计.
如果你的数据天生就是对象,那么请使用对象存储(NoSQL),它们要比关系数据库快得多.
如果你的数据天生就是关系型的,那么关系数据库带来的开销是值得的.
把你的关系查询封装在模型层中,设计你的API从而为应用提供数据访问支持;拒绝过分泛化的诱惑.
面向对象无法以有效的形式表达关系数据;这是面向对象设计的一个基本限制,ORM无法修复它.
只能说明你不爱思考
框架有好处。也有不足。
我也是才入门PHP。开发不到半年。看过几天laravel
感觉totally overwhelmed 。
主要是它的思想和我们用的一些东西不一样。
但我觉得真没有必要把框架都学。毕竟每个人情况不一样。也没必要一味的鼓吹lara有多优秀。原来没用laravel网站不也一样开发出来了膜？
我敢说。国内的网站用lara的真不多。
lara对于方法命名等限制很死。在获得统一的同时也在失去自由。对新手形成规范还不错。但是你以及非常熟悉了。完全没必要去在意这些。天天出现的框架这么多。你能说每个都会膜。语言也非常多。你能都学一次膜？适合自己的才是最好的！就像ORM一样。一定要用他膜？还query builder之内。有时候反倒不如直接functional programming 来的快。很简单就可以完成的东西。硬是要套无数层。真是好的方式膜？还有模版引擎！一定需要膜? 我承认欧美技术比中国强。但也不一定要跟着他们走。对吧？
很简单的一个例子。用框架上传文件真是不方便。
进行分页也不方便。甚至URL的地址取名字使用都不方便。因为大部分是单入口。比如一个API的要进行分页。比如多文件上传。单独修改其中的某个文件。比如多个分页。我才入门。新手。有些话可能有不对。灵活性框架真太差。
在理解MVC和package管理以及一些面向对象的基础学laravel 就快了。其实看不懂还是不理解，不理解他的这种组织结构会带来什么好处，一个简单的请求明明对应一个php文件就解决了，laravel 却搞得复杂的不行。。。主要还是MVC分层及注入对于项目管理维护带来了很大的好处才这样子设计的。
看不懂就先照着做例子吧，仔细研究浏览器发出一个请求直到服务器输出内容到页面，这期间laravel 框架都做了哪些事情以及为什么要这样设计。相信会对你有帮助。
换个语言玩玩,python之类的.然后回头看会有新的体会,跟php这种cgi方式架构会很不同
我多说一句和本问题无关的话，楼主请见谅。因为看到很多的评论后我觉得有必要说说我的一点看法。
我建议刚开始编程的同学应该好好读读 《软件工程》这本书，你会发现计算机界一直在寻找一种软件开发方法可以让软件开发变得就像盖房子一样可以像预期那样的成功。ibm的rational,极限编程，Scrum，敏捷，面向对象等等你可以听到的几乎所有的这些东西最终都会聚集到一个点：如期开发出一个符合预算，满足客户要求的易维护可扩展的软件。哦，原来所有的这些东西都是为了解决这么一个问题,他大爷的，原来如此，豁然开朗。
Larval，一件PHP程序员的利器，会使用就可以披荆斩棘，不会用那就换一个，每个人都有适合他的武器，你要找到你的武器，但是不管你用什么武器，都要记住最终的那个点。否则，你永远都不可能知道为什么有人说这段代码很优雅，而有的人说这段代码是狗屎，至于它到底是狗屎还是优雅，只有真正懂的人才会明白，不懂的人你和他说再多也是狗屎。
如果有一点其它框架的基础的话，学习laravel应该比较容易，我也初略接触过其它的一些框架，像yii，ci，感觉laravel用起来确实要舒服一点。
刚开始学习一个框架确实比较吃力，特别是理解它的一些思想，不过当你会用了，就会感觉开发轻松多了，至于性能和执行效率什么的，应该差别都不是很大。
建议看看spring 尤其要结合实际项目的教程 然后对里面的的一些实际就知道来龙去脉了 laravel的写法很传统的php还是有一些理念上的差异的
推荐我学习框架的方法
抱着使用它的态度来学。
用它来做项目，在实现的过程中学习它。不要把它视为多高深的学问，这样它就不会显得那么困难。
我也是php新手，以前写php没什么框架的概念，现在接触laravel两个月，一个人就可以做出一个项目了。我觉得要学一个东西，拿它来实际操练才能最好的锻炼自己吧，仅仅看是没什么用的，当你用会了之后，在回去看一些文卓或书籍，就能进一步理解框架了
php本身就是一套自带模板的插件,根本不需要框架 但实际上为什么现实中就数php的框架最多呢? 主要因为php太简单了,以致于简单到让半吊子们码农没法拿到台面上来给别人装逼,所以一大波半吊子码农热衷写各种奇形怪状的框架,茴香豆一要这么写才足够上档次,跟这些框架的拥甭们争论到最后,都认为框架既提高不了实际项目开发效率,也无法提高程序的运行效率,在需求业务快速迭代的场景下也不能有效地根据需求扩展 唯一能拿出来说事的就是框架能规范团队统一代码风格, 这本来就是一张纸就能解决的事情, 如果是rails那样的大一统框架,至少到哪家公司都是统一的风格,但是象php这样多如牛毛的框架中,码农如果换了一家公司,以前积累的"风格"就没用了,一切又要从头开始熟悉新的风格了,php码农的青春就消耗在这些多如牛毛的框架中熟悉各种各式的"风格"里,过个5,6年,老板觉得码农已经不熟悉现在市场最新流行的框架风格了,把码农一脚踢飞了
跟着大势，现在最流行的是laravel，只能去适应
这里有个文档攻略：http://laravelbase.com/
也许会有帮助
laravel，框架挺好的，文档是个渣渣
看到了评论很多，也想说几句。尽管这是很久以前的一篇讨论，题主不见得会看到。
首先我很赞同楼上一位兄弟所说。
没必要做太多关于框架，关于各种不同语言之间的争论，没有太多意义。
一门语言创建之初，是有它明确的定位的，现在太多人认为一门语言解决所有的问题和现实中的需求，这本身就不切实际。
无论是框架还是语言，它的出现肯定有它擅长的能力或特性。
回归到原点，我们码代码无非是要解决现实中的问题。
在解决问题之初，本身就应该从架构方面来考虑，根据团队成员情况，根据项目复杂程度，根据项目时间紧急，根据以后的维护成本，根据投入，等等很多因素，然后综合来决定选择使用那种方案，使用哪种框架亦或者是自开发框架（或约定及统一的代码组织方式），亦或者是不使用框架。
以上这些其实都不重要。
重要的是让你，或者你的团队，你的公司，能快速的，或者更好的来解决问题。降低可能产生的不必要的成本。
所以新语言的出现，或者是新框架，新思想的出现，最终目的无非如此。
无需为了语言而语言，为了框架而框架。
最快，最好，最舒服，最安全，最好维护，最好协作，以及最合适的完成预期目标，才是目的，才是王道。
至于题主所提laravel文档，这个我个人觉得一是官方文档本身书写比较简单，简单有简单的好处，起码东西不会过多，导致入门困难。如果想深度了解设计思想，需要去看代码和api。
其次，要想快速的了解，最好的办法是先了解它大的流程，知道它的运行原理，细节方面慢慢来就好。
剩下的就是，去用它而已。