LAMP架构下的Web开发概念、流程及优化策略(二)-阿里云开发者社区

开发者社区> 开发与运维> 正文

LAMP架构下的Web开发概念、流程及优化策略(二)

简介:

六、目前流行的PHP框架 

应用场景二: M (业务模型,应用者编写)

C (业务控制器,应用者编写,由框架控制器自动载入)

V (视图,应用者编写,框架自动载入)

现实中复杂应用场景:

1.用户请求: http://domain/blog/list/

2.分析URL,实例化逻辑控制类blog,执行方法list

3.在控制类news,又分别实例化业务模型类bloguser,并做相应处理.

4.业务模型类blog,user,调用数据模型(专用,M),对数据进行处理.

5.回到逻辑控制类中,展现视图$this->view->output( );

 

运用中需要注意的地方

 PHP没有持久层,每一次访问请求都是独立运行,建立的模型对象不能持久存在,无法跨访问复用.如果框架/应用的设计过于繁琐,每次装载/初始化都会浪费不少时间.

 各层之间的耦合度尽量降到最低,尤其是业务模型和业务逻辑之间要尽量分离.以便日后修改或复用.

 PHP本身只有较少功能是抛出异常,大部份是抛出错误(Notice,warning,error),代码编写中应时常对应用环境的正确性做手工检查,不符合条件时手工抛出异常,并设置异常接收器统一处理

 

 单入口模式

http://domain/index.php?control=blog&action=list

http://domain/index.php?control=news&action=read

 多入口模式

http://domain/blog.php?action=list

http://domain/news.php?action=read

 PathInfo模式

http://domain/index.php/blog/list/

http://domain/index.php/news/read/

 Rewrite模式

http://domain/blog/list/

http://domain/news/read/

Rewritepathinfo的好处:对搜索引擎友好,对用户更直观

 

九、数据库抽象层、Active recode

 数据库抽象层的作用

减少与具体数据库的底层接触,提供跨数据库平台的访问接口,以实现数据操作与数据库类型的无关性.方便数据库系统的迁移变更.

 PHP本身提供的抽象层

Pear::DB(php4),PDO(php5,6)

 框架中引入的各种类Active Recode系统

目的:将数据库字段与映射到对象,不用关心具体的SQL语句,只需要操作数据对象及调用相关的方法即可实现数据的CRUD操作。

好处:模型化了数据库,快捷开发,是数据库抽象层的进一步进化。

缺点:对于复杂数据模型的处理较为无力,例如多表连查、子查询。

缺乏灵活性,比如只想要一列数据,却取出了整行。

与数据库字段名的耦合度太高。如通过配置改进,执行效率又打折扣。

难以应付复杂的Web环境。(多种数据库,分布式数据库,缓存系统介入)

 

十、模板引擎

  

 为什么引入模板引擎

视图:在web开发中通常就是指前端页面。模板引擎的引入,是为了实现视图层的分离,降低视图与逻辑、模型部份的耦合度。使得前端页面与程序部份可以并行工发、轻松整合的工具

 常见的模板引擎及特点

PHP中常用的模板引擎有 Smarty, SmartTemplate

其中smarty提供了强劲的功能,STE则非常轻巧。

两者的核心原理,都是将页面中的变量标签替换成通过assign方法注册的PHP运行变量,并将替换后的页面(“编译”后的页面文件)生成缓存保存在磁盘中。或者提供一定的逻辑控制功能供前端使用。这样即方便将程序和视图分离,使前端设计人员更着重于表现和数据,而不用关心程序上的流程.

 缺点

初次加载模板时,因生成缓存,需要额外的处理开销和IO开销

之后加载模板时,会判断模板文件的最后修改时间是否大于生成的缓存文件时间,亦有一定的额外IO开销.

 

使用模板引擎的注意事项

 

 

 

八、访问模式 

 

 Qee /FleaPHP (领域设计驱动)
 ThinkPHP (大的类库J
 Zend FrameworkPearOOP版)
 Yii 
 KiwiPHP (工业微内核)
 Symfony (配置最简单)

七、WEB中的MVC开发模式

应用场景一: M (数据模型,框架提供)

C (控制器,框架实现)

V (视图,应用者编写,框架自动载入)

应用者编写的,是供控制器装载的业务处理类

 

 

 尽量折分公用组件。

 

 不要在视图中使用太多的控制语句

就以前的经验来看,简单的if,变量循环输出即已足够。

在视图中加入太多的控制语句会带来的问题,是对设计思想的破坏,因为它打乱了将视图层独立出来的最初目的,让前端的设计人员不得不过多的关注“程序”而非页面本身。要不然就得由程序员最终回头修改前端设计人员已经做好的模板文件。

更重要的一点时:如果在模板中引入太多的控制语句,那还不如直接在页面中写<?php ,因为PHP的本身就是模板引擎。无论哪种都快不过它。

所以,尽量将控制放在PHP程序体内,不要放到视图中去跑.

 

十一、LAMP架构下的加速系统

 

 

十二、各级加速系统说明

 

 

 

 WEB服务层

Nginx :自身支持反向代理,提供简单的负载均衡及从错机制,能很方便的搭建起web服务集群.

Lighttpd:超轻量,合适搭建静态访问服务器

Squid:对动态内容亦能做缓存处理.

 PHP

APC:缓存opcode,减少了扫描和编译阶段,但仍无法实现持久对象.纯脚本效率提高在200%--500%,应用场景下实测通常能提高效率一倍.

XCACHE

 数据层

共享内存

Memcache: Key=>Value对形式的内存数据缓存服务.基于TCP连接.常用于缓存数据库查询结果.支持分布式.

缺点:关机即无,每次连接的时间开销大.

 

 

 

 

推荐的工具

 

 Editplus+PHP

 XDEBUG+Eclipse PDT

 SmartTemplate

Xdebug+ WinCacheGrind
 

 

【本文首发于:百度运维空间http://hi.baidu.com/ops_bd/blog/item/ae1a7b16c2a6b06acb80c4dd.html
关注百度技术沙龙












本文转自百度技术51CTO博客,原文链接:http://blog.51cto.com/baidutech/748346,如需转载请自行联系原作者

版权声明:本文首发在云栖社区,遵循云栖社区版权声明:本文内容由互联网用户自发贡献,版权归用户作者所有,云栖社区不为本文内容承担相关法律责任。云栖社区已升级为阿里云开发者社区。如果您发现本文中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,阿里云开发者社区将协助删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章