Laravel5.1 学习笔记1, 目录结构和命名空间(待修)

自从用 Laravel4做了个小网站,使用了数据库ORM Eloquent, 就放下了一段时间,想不到这个与Asp.net MVC 有着异曲同工之妙的框架已经出了下个版本,而且还有不小的改动,因此不得不从头过一次,顺便更新一下知识点。

下面内容摘自Laravel 5.0 系列, 目录结构和命名空间

Laravel从4升级到5 ,改变的不只是文件的组织方式,而且是思想上的重大转变。 废话不多说, 新版本的目录。

app    Console        Commands    Events    Exceptions    Http        Controllers            Auth        Middleware        Requests    Jobs    Listeners    Providersbootstrap    cacheconfigdatabase    factories    migrations    seedspublic resources    assets    lang    viewsstorage    app    framework        cache        sessions        views    logstestsvendor

而在新的目录结构下, 它只包括应用逻辑(包括业务领域), 并且遵循 PSR-4 规范来进行类的自动加载。

 

由此带来的是, Laravel 相关的配置文件保存在了自己的独立目录下, 资源文件--语言和视图--保存在了自己的独立目录下, 数据库相关的信息也保存在了它们自己的目录下。

 

最后,原来写在过程文件(比如 filters)中的代码现在移到了类和 Service Providers 中. 可以减少过程代码, 使执行更容易预测。同时也鼓励对 Service Providers 的用户态使用(即 "在我们的代码里,而不是在框架代码里")。

xxx 应该放在哪里?

如果 xxx 代表的是某个类, 或者可以写成一个类的话, 它应该放在 app/ 下的某个地方. 如果 xxx 代表的是 Eloquent model, 它应该放在 app/ 下的某个地方。如果 xxx 要通过 Web 服务器来处理发送给请求流(比如 Controllers 和 FormRequests), 它应该放在 app/Http 目录下。如果 xxx 要通过 CLI (命令行界面) 来处理请求, 它应该放在 app/Console 目录下。如果 xxx 在以前的版本中是放在 routes.php 文件中(但它不是一个路由定义), 或者是放在 start.php 文件中, 那么现在它应该写到某个 Service Provider 里。如果 xxx 是一个过滤器(filter), 它应该放在app/Http/Filters 目录里一个专属于它的类中。

如果 xxx 不属于上面的任何一种情况, 那么从目录结构就可以很清楚看出它应该放在哪里了。

 

代码中的命名空间(namespace)是怎么工作的?

默认情况下, 每个 Laravel 应用都有一个代表应用类的顶级命名空间, 一般来说这个命名空间是 "App", 它对应的着 app/ 目录, 遵循 PSR-4 规范。

但你只要执行一个 artisan 命令, 可以很轻松地修改 "App/" 下所有实例的根命名空间。

比如新建了一个 Laravel 项目之后, 可以马上执行下面的 artisan 命令, 把根命名空间从 "App" 改为 "Confomo":

$ php artisan app:name Confomo

执行完这个命令之后, app/ 目录下的所有类都被归入 "Confomo" 命名空间下下.composer.json 文件里的 PSR-4 自动加载语句会自动更新, Laravel 也清楚应该在哪里去寻找该命名空间下的 filters, controlers 等。下下

composer.json 文件里的 PSR-4 自动加载语句会自动更新, Laravel 也清楚应该在哪里去寻找该命名空间下的 filters, controlers 等。

时间: 2024-09-29 20:46:15

Laravel5.1 学习笔记1, 目录结构和命名空间(待修)的相关文章

thinkphp学习笔记1—目录结构和命名规则

最近开始学习thinkphp,在下不才,很多的问题看不明白所以想拿出来,恕我大胆发在首页上,希望看到的人能为我答疑解惑,这样大家有个互动,学起来快点,别无他意,所谓活到老,学到老,希望各位不要见笑啊. 我的做法很简单,先从手册开始,手册是开发thinkphp作者辛勤劳动的成果,但是有些地方是在是不懂,如果有幸各位也遇到类似的问题希望能回复.thinkphp手册地址:http://doc.thinkphp.cn/manual.html 1.框架目录 在章节1.6 目录结构,内容如下: 新版的目录结

Linux Shell 学习笔记 一 目录结构

以Red Hat Enterprise Linux 各版本为例,RHEL中目录具体作用如下, /bin       存放普通用户使用的命令 /sbin     存放管理员可以执行的命令 /home   存放普通用户的家目录 如zhangshan家目录为/zhangshan /root     管理员的家目录 /etc       存放配置文件的目录 /boot     存放跟启动相关的文件 /usr       用户自定义的相关程序文件 /porc     内核,硬件参数相关的目录 /var  

html5学习笔记(3)--主题结构元素-1

html5学习笔记(3)--主题结构元素-1 Article元素 以下为对应代码: <!DOCTYPE html> <html> <head lang="en"> <meta charset="UTF-8"> <title></title> </head> <body> <article> <header> <h1>极客学院</h

设计模式学习笔记(目录篇)

设计模式学习笔记(目录篇) 为了方便查看,特此将设计模式学习笔记系列单独做一个目录. 1   设计模式学习笔记(一:命令模式) 2   设计模式学习笔记(二:观察者模式) 3   设计模式学习笔记(三:装饰模式) 4   设计模式学习笔记(四:策略模式) 5   设计模式学习笔记(五:适配器模式) 6   设计模式学习笔记(六:责任链模式) 7   设计模式学习笔记(七:外观模式) 8   设计模式学习笔记(八:迭代器模式) 9   设计模式学习笔记(九:中介者模式) 10  设计模式学习笔记(

Magento学习第一课——目录结构介绍

Magento学习第一课--目录结构介绍 一.Magento为何强大 Magento是在Zend框架基础上建立起来的,这点保证了代码的安全性及稳定性.选择Zend的原因有很多,但是最基本的是因为zend框架提供了面向对象的代码库并且有很好的团队支持.通过这个框架,Magento主要围绕三个基本点建立: 1. 灵活性:我们相信每一个解决方案都像它的商务支持一样是独一无二的.Magento的代码可以无缝定制的. 2. 可升级性:Magento可方便的实行定制且不丧失升级的能力,因为从社区中获得核心代

Laravel5的新特性 - 目录结构和命名空间

Laravel5的新特性 - 目录结构和命名空间 从Laravel4.2升级到Laravel5最大的一个原因就是因为目录结构的调整.Laravel5的目录结构能够更好的帮助人们理解web开发的最佳实践,对WEB的规范化将会做出不小的贡献.那么,Laravel5的目录结构是什么样的呢? app Commands Console Events Handlers Commands Events Http Controllers Middleware Requests Providers Service

NDK学习二: NDK目录结构

NDK目录结构 NDK下载好之后目录结构如下: 目录名 描述 build   存放和编译相关的脚本文件,最外面的ndk-build就是调用该目录下的makefile文件,其中makefile文件都存放在build/core目录 docs  帮助文档 platforms  存放不同android版本,不同平台架构的头文件和库文件 prebuilt  存放和编译相关工具比如make.exe samples ndk代码例子,用根目录下的ndk-build即可编译 source 源码目录,有一些头文件和

学习笔记: Linux目录,inode

目录,inode学习笔记 1. 关于目录,文件,数据块 对于使用计算机的人而言,经常有一种 错误的认知:目录(或者说,文件夹)里面存放着文件.实际上,目录里面并不存放文件,以及文件数据. 实际上,目录是一个特殊的文件,针对这个特殊的文件也存在一些特殊的规则,比如利用命令cp /dev/null <your directory>并不能够销毁这个特殊的文件,因为目录的一些特殊的比特位保证了这一安全性,降低了人工操作带来的风险.在一些老版本的Unix系统里面,用户可以利用cat命令打开目录,查看里面

python学习day4软件目录结构规范

为什么要设计好目录结构? 参考:http://www.cnblogs.com/alex3714/articles/5765046.html "设计项目目录结构",就和"代码编码风格"一样,属于个人风格问题.对于这种风格上的规范,一直都存在两种态度: 1.一类同学认为,这种个人风格问题"无关紧要".理由是能让程序work就好,风格问题根本不是问题: 2.另一类同学认为,规范化能更好的控制程序结构,让程序具有更高的可读性: 我是比较偏向于后者的,因为