标签：
从Laravel4.2升级到Laravel5最大的一个原因就是因为目录结构的调整。
Laravel5的目录结构能够更好的帮助人们理解web开发的最佳实践，对WEB的规范化将会做出不小的贡献。那么，Laravel5的目录结构是什么样的呢？
app
Commands
Console
Events
Handlers
Commands
Events
Http
Controllers
Middleware
Requests
Providers
Services
bootstrap
config
database
migrations
seeds
public
package
resources
lang
views
storage
cache
logs
meta
sessions
views
work
tests
Laravel5之前的目录结构是比较经典的CodeIgniter风格，目录包含所有的应用程序的逻辑、框架、模板等等。而Laravel5的目录更偏向将应用程序的业务逻辑通过目录表现出来[应用了PSR-4标准]。
Laravel5的配置文件、资源、缓存、数据库相关等都有了独立的目录。也在为应用程序在大数据时期能够顺利的将各个功能分别部署到不同的服务器上去。Laravel5也添加了云存储，后面的文章会具体介绍。
很多人会问，Laravel5的目录结构的变化真的是一种提升么？
首先，目录的变化使我们更加关注业务逻辑。之前，App目录包含了除了前端资源剩下的所有代码，但现在，App目录只包含了核心业务逻辑，其它一些实现的细节则放在了公共目录下。
此外，Laravel5在相当一段时间内被认为是最佳实践，系统默认所有的业务逻辑都在一个‘App‘命名空间下。对于大多数人来说，新建一个项目，会删掉一些框架自带的模型目录或者文件，但Laravel5就可以使用命令修改App名称：
php artisan app:name Blog当然，我一般会选择使用默认的app名称。但是在更改了app名称之后，你可以更加清晰的理清Laravel5的目录结构，哪些是属于应用程序的，哪些是属于公共程序。修改app默认名称来理解Laravel的目录结构到是非常不错的一种选择。
最后，通过composer，大量的代码利用第三方的类或者服务提供商来维护，我们的程序只需要关注核心的业务逻辑。这使得代码执行更容易预测，降低的程序的代码量，也使得代码的稳定性和安全性有了大的提升。
如果说应用程序目录应该独立太极端。Controller、MiddleWare、Command和ServierProvider或者你自己的类文件都可以继承或者依赖注入Laravel的类。所有的第三方类都是有自己的服务提供商来维护的，理论上我们的应用逻辑基本是可以独立存在的。
如果它是一个类或者可能是一个类，它应该在App下面。
如果它是一个Element Model，它应该在App下面。
如果你想通过Request请求来控制应用程序的流程，那么它应该在App/Http下面。
如果它是与CLI（命令行接口）关联，那么应该放在App/Comsole下面.
如果是前端需要访问到的资源，需要放到/public目录下。
除此之外的一些文件都应该比较清楚。
默认情况下，每个应用程序都有一个命名空间，‘App’表示应用程序的顶级命名空间。Laravel5早期的版本会通过composer.json配置映射App目录下的一些目录，所以早期版本在App目录下使用类的时候不需要定义命名空间，使用类文件的时候直接从App以下的目录开始。
但Laravel5之后，就取消了这种做法，这种做法的缺陷一是在项目变大之后自动载入map过大导致性能下降；二是使用别名的做法在抛出异常的时候可能会出现Bug；第三也是为了迎合多应用开发做准备。所以，在Laravel5以后，大家还是规规矩矩的使用命名空间和use关键字。
Laravel5的新特性还在继续，敬请关注小白巷~
标签：
原文地址：http://www.cnblogs.com/jroy/p/7c43bff9-b57d-41ba-a768-064bad48bf99.html
