今天的协同开始里MVC已经是广为达成共识,就像和平与发展是21世纪的主题,之前的代码都是层与层区别的不明显,html和PHP混合开发,效率不高,1999年,sun公司的J2EE,是最早最完整的MVC模式。
优点:
多个view共享一个Model。View负责负责格式化并把他们呈现给用户,业务逻辑和表示层分离,同一个Model可以被不同的View重用,大大提高了代码的可重用性。Controller是高独立内聚的对象,与Model与View保持独立。Controller提高了应用程序的灵活性和可配置性。MVC模式强调职责分离,带来了一个现代软件工程要求的重要特征:可测试性,基于MVC的程序良好的职责分离设计下,各个部分可独立进行单元测试,利于自动化测试,集成等诸多优点。
缺点:
MVC应用会产生很多文件,对于PHP这种不能常驻内存的语言来说,大量的文件加载和变量造成了大量开销。初学的程序员不容易理解。Composer,来实现和引入第三方类库,并利用其实现依赖管理和自动升级。
Composer解决的问题:
你有一个依赖N多库的项目这些库中一些项目又依赖于其他的库你声明你所依赖的库Composer找出那些包那个版本将会被安装安装及使用
//安装命令 curl -sS https://getcomposer.org/installer | php //设置全局变量 mv composer.phar /usr/local/bin/composerComposer常用命令:
// 从当前目录读取composer.json文件,处理了依赖关系,并把其安装到vender目录下,如果当前目录下,如果当前存在composer.lock文件,他会从此文件读取依赖版本 composer install //获取依赖的最新版本,并且升级composer.lock文件 composer update //打印自动加载索引,某些情况下你需要更新autoloader,例如在包中加入了一个新类。 composer dump-autoload加载方式:
PSR-0
PSR-4
class-map
直接包含file
{ "autoload": { "psr-4": { "Monolog\\": "src/", "Vendor\\Namespace\\": "" } } }composer 加载原理:key和value就定义了namespace以及其对应的目录映射。 当试图自动记载 Vendor\\Namespace\\类的使用时,会去寻找src/这个文件,如果它存在自动加载,要注意的是此时Vendor\\Namespace\\并不会出现在文件路径中。
而composer.json这样的配置会被Composer 转换成 namespace 与文件目录的MAP形式,并存在vender/composer/autoload_psr4.php文件中。所以如果你安装的某个扩展自动加载是PSR-4形式,你可以在autoload_psr4.php找到他的真实路径。
Composer优点:
更加集中管理\自动加载类库统一管理第三方类库,支持升级扩展CI框架的优点:
单入口:使得每一个请求都需要经过对这个入口文件处理,文件由此进行,Controller层的管理变得轻而易举,开发者可以在这个入口实现很多针对Controller层甚至View层的统一管理,比如设置字符集,CSRF过滤等。
MVC朝着轻量化、API化发展了(主要JavaScript+Json形式)