简体中文（ZH-CN）English（EN）繁体中文（ZH-TW）日本語（JA）한국어（KO）Melayu（MS）Français（FR）Deutsch（DE）
首页
文章
问答
课程
专题
下载
手游
词典
最近更新

首页  >  问答  >  正文

PHP也做好好多年了，最近在看laravel框架，但是面对如此丰富的文档，我却不知道在讲什么，完全看不懂，请问我是哪里出了问题？

如题，苦恼啊！
我该怎么办呢？
求有经验的前辈大哥给点指点！
谢谢！

PHP中文网PHP中文网2772 天前5473

全部回复(29)我来回复

  • 巴扎黑

    巴扎黑2017-04-10 16:40:43

    php本身就是一个框架，真正的php的最高境界就是无框架，即使你需要框架，也要自己写框架，自己写出来的框架才是世界上最好的框架

    回复
    0
  • ringa_lee

    ringa_lee2017-04-10 16:40:43

    框架的作用是减少代码量，并且让软件变得有组织结构。

    也就是说，框架在一定程度上封装了许多开发中常见的操作，并且可能做了更多扩展。

    当然，你也可以在框架中使用$_GET取参数，虽然提高了效率，但是这样的话就无法从框架中获益。

    用好一个框架必须要有全局的意识，还有不断的学习和总结。

    回复
    0
  • PHP中文网

    PHP中文网2017-04-10 16:40:43

    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是不是最佳实践？ 我也无法回答。但是我可以肯定的是它是符合现代开发流程的。

    回复
    0
  • 高洛峰

    高洛峰2017-04-10 16:40:43

    优雅不优雅不说，谁能告诉我，用composer安装了几个过度封装的包（包括阿里云的oss sdk及其他）,xhprof打出来的堆栈几乎让我想哭，一个业务逻辑在xhprof采样后，转出来的dot文件有3k+行，用dot渲染成jpg要花十分钟…………
    我就只想简简单单的支持业务，优雅爬开。

    回复
    0
  • 巴扎黑

    巴扎黑2017-04-10 16:40:43

    我们学习PHP,不仅是因为它强大,更是因为它简单.
    PHP的成功,不是因为那些框架,而是WordPress这些新手都能搭起来的应用.
    所以,别被那些整天鼓吹XXX框架的拥趸给蛊惑了.

    就拿一个文章页实现来说:

    /post.php                     //页面控制器(处理输入,调用模型,输出视图)
/inlcude/common.php           //执行一些公共操作
/include/functions.php        //模型(SQL增删改查,系统函数)
/themes/default/post.php      //视图
/themes/default/header.php    //公共头部
/themes/default/footer.php    //公共尾部
/themes/default/functions.php //主题自定义函数

    像这种一目了然的代码结构,想不看懂都难,而且一样能分离界面跟逻辑,实现MVC.

    前端控制器(路由)并不是实现MVC必需的设计模式.
    MVC的核心思想是分离界面(View),逻辑(Controller),数据(Model).
    比如浏览器访问页面控制器,控制器处理输入,调用模型获取数据,载入视图输出数据.
    PHP几句代码就能轻松实现MVC:

    /post.php?id=1024 //页面控制器(输入ID,输出文章)
<?php
if(!defined('APP_ROOT')) define('APP_ROOT', './'); //定义入口
require APP_ROOT.'include/common.php'; //加载模型(比如functions.php)
$data = get_post(intval($_GET['id'])); //处理输入,调用模型获取数据
$view = render('post.php', $data);     //载入视图输出数据
echo $view;
//在控制器中获取视图需要的所有数据,并封装到$data数组中,传入视图.
//如果你想在视图里直接调用数据$data,可以把render函数改为require.
//这样视图跟控制器都在同一作用域,灵活性更强,但也要注意,尽量不要在视图里写具体逻辑.
//视图应该专注于调用并输出数据.

/include/functions.php里的render()函数:
function render($template, array $data = array()) {
    global $app;
    ob_start();
    require APP_ROOT.'themes/'.$app['theme'].'/'.$template;
    $view = ob_get_contents();
    ob_end_clean();
    return $view;
}

    PHP自身提供的那么多超全局变量,是给用户用的,不是给框架封装的.
    大多数函数都依赖数据库连接,PHP的话完全可以在函数内用global $mysqli,
    从而拿到全局的MySQL连接对象进行CRUD操作,简单直观.
    为什么一定要用依赖注入?搞那么复杂干什么.
    很多人都觉得全局变量没有OOP的依赖注入那么优雅,但优雅能当饭吃吗?
    为了优雅,是不是连PHP提供的超全局变量也不用了?简单直观才是PHP的王道.
    比如按需动态生成全局的数据库连接对象:

    <?php
// config.php
$app = array('db_conn' => '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无法修复它.

    回复
    0
  • 黄舟

    黄舟2017-04-10 16:40:43

    只能说明你不爱思考

    回复
    0
  • ringa_lee

    ringa_lee2017-04-10 16:40:43

    框架有好处。也有不足。

    我也是才入门PHP。开发不到半年。看过几天laravel
    感觉totally overwhelmed 。
    主要是它的思想和我们用的一些东西不一样。
    但我觉得真没有必要把框架都学。毕竟每个人情况不一样。也没必要一味的鼓吹lara有多优秀。原来没用laravel网站不也一样开发出来了膜？
    我敢说。国内的网站用lara的真不多。
    lara对于方法命名等限制很死。在获得统一的同时也在失去自由。对新手形成规范还不错。但是你以及非常熟悉了。完全没必要去在意这些。天天出现的框架这么多。你能说每个都会膜。语言也非常多。你能都学一次膜？适合自己的才是最好的！就像ORM一样。一定要用他膜？还query builder之内。有时候反倒不如直接functional programming 来的快。很简单就可以完成的东西。硬是要套无数层。真是好的方式膜？还有模版引擎！一定需要膜? 我承认欧美技术比中国强。但也不一定要跟着他们走。对吧？

    很简单的一个例子。用框架上传文件真是不方便。
    进行分页也不方便。甚至URL的地址取名字使用都不方便。因为大部分是单入口。比如一个API的要进行分页。比如多文件上传。单独修改其中的某个文件。比如多个分页。我才入门。新手。有些话可能有不对。灵活性框架真太差。

    回复
    0
  • 黄舟

    黄舟2017-04-10 16:40:43

    在理解MVC和package管理以及一些面向对象的基础学laravel 就快了。其实看不懂还是不理解，不理解他的这种组织结构会带来什么好处，一个简单的请求明明对应一个php文件就解决了，laravel 却搞得复杂的不行。。。主要还是MVC分层及注入对于项目管理维护带来了很大的好处才这样子设计的。

    看不懂就先照着做例子吧，仔细研究浏览器发出一个请求直到服务器输出内容到页面，这期间laravel 框架都做了哪些事情以及为什么要这样设计。相信会对你有帮助。

    回复
    0
  • 天蓬老师

    天蓬老师2017-04-10 16:40:43

    换个语言玩玩,python之类的.然后回头看会有新的体会,跟php这种cgi方式架构会很不同

    回复
    0
  • 巴扎黑

    巴扎黑2017-04-10 16:40:43

    我多说一句和本问题无关的话，楼主请见谅。因为看到很多的评论后我觉得有必要说说我的一点看法。

    我建议刚开始编程的同学应该好好读读 《软件工程》这本书，你会发现计算机界一直在寻找一种软件开发方法可以让软件开发变得就像盖房子一样可以像预期那样的成功。ibm的rational,极限编程，Scrum，敏捷，面向对象等等你可以听到的几乎所有的这些东西最终都会聚集到一个点：如期开发出一个符合预算，满足客户要求的易维护可扩展的软件。哦，原来所有的这些东西都是为了解决这么一个问题,他大爷的，原来如此，豁然开朗。

    Larval，一件PHP程序员的利器，会使用就可以披荆斩棘，不会用那就换一个，每个人都有适合他的武器，你要找到你的武器，但是不管你用什么武器，都要记住最终的那个点。否则，你永远都不可能知道为什么有人说这段代码很优雅，而有的人说这段代码是狗屎，至于它到底是狗屎还是优雅，只有真正懂的人才会明白，不懂的人你和他说再多也是狗屎。

    回复
    0
  • 取消回复