1. LAMP架构下的Web开发 概念、流程及优化策略

2. 开发阶段常规步骤

3. 架构设计 浏览器版本，系统环境等 Nginx Apache IIS…. Jquery,EXT…. Mysql MSSQL ORACLE Php Python Ruby java Memcache APC 共享内存……. 按钮 菜单 ….. 布局层次 CSS结构 前端细节约定 图片分离 小文件存放 分布式存放

4. 接口约定 约定请求方式（普通HTTP请求，XMLHTTP请求，SOAP请求，phprpc请求）、请求类型（POST,GET,HEADER）、请求地址、请求参数。（前端请求四要素，文档中体现，程序中实现。） 标识约定 为确保前后端并行开发，减少开发的时间周期，需要在开发前就做好标识约定，通过文档描述清楚前端模板变量和后端程序变量之间的约定关系，以及后端返回各种状态值的含义。 建议的最佳应用是：后端不对用户视图负责，只管输出状态代码。呈现给用户的视图由前端负责。 对接约定

5. Nginx 优点：原生支持反向代理，带有简单的负载均衡及容错机制。速度最快。（10%-1000%），占用资源很少。 缺点：文档较少，手工配置，只能以fast-cgi方式运行php. Apache 优点：文档丰富，稳定（！？），应用环境多。 缺点：占用资源较多，高压力下表现性能不如nginx或lighttpd，手工配置。 IIS 优点：文档丰富，win平台下安装简单配置方便 缺点：不支持跨平台，性能低下。 各类web服务器优缺点比较

6. 常见web系统组织图 文件访问服务器 Images,other…. 反向代理 静态缓存服务器 数据库或缓存服务集群 Web应用服务器 数据代理中心

7. 语言弱类型 脚本运行，生命周期短。 面向对象与面向过程并存。 弱效率、重流程、强扩展。 PHP在web应用中的特点

8. 适合web开发。将web开发中常用的行为、内容做了良好的封装。程序员可以很轻易的使用它们。 基于脚本的运行方式，修改代码后不需要重新编译，很多情况下也不需要重启服务器。 开发快捷，部署方便，支持环境众多。 非常优秀的扩展能力。非常多的扩展子件。 开发框架众多。对多种数据库支持很好 良好的社区支持，本身开源。修改容易 PHP的优点

9. 容易写出坏的代码。(解决方法:严格遵循规范) 效能不高。（解决方法:复杂业务使用C扩展） 每次执行都要经历 扫描-编译-执行 的阶段，无执久对象模型。（解决方法:使用APC） 命名混乱，参数混乱，得随时翻着手册 PHP的缺点

10. 对开发者起编码约束作用。 提供了ORM,使对数据库变成对数据对象的访问,让程序员对数据的处理更加专注于面向对象上. 通过配置(无需改动代码)即能变更服务环境,使得迁移成本减小 方便程序员实现完整的MVC开发模式.使程序员更专注于业务领域,不再过多关注建立数据模型的底层代码以及处理视图展示. 内置大量开发中的常用工具。可随时调用。也可自己扩展编写。 本身即由PHP编写。可随时修改以满足达到自己的需求。 PHP框架

11. Qee /FleaPHP (领域设计驱动) ThinkPHP （大的类库 ） Zend Framework （Pear的OOP版） Yii KiwiPHP （工业微内核） Symfony （配置最简单） 目前流行的PHP框架

12. WEB中的MVC开发模式 应用场景一: M (数据模型,框架提供) C (控制器,框架实现) V (视图,应用者编写,框架自动载入) 应用者编写的,是供控制器装载的业务处理类. 应用场景二: M (业务模型,应用者编写) C (业务控制器,应用者编写,由框架控制器自动载入) V (视图,应用者编写,框架自动载入) 现实中复杂应用场景: 1.用户请求: http://domain/blog/list/ 2.分析URL,实例化逻辑控制类 blog,执行方法 list 3.在控制类 news中,又分别实例化业务模型类 blog和user,并做相应处理. 4.业务模型类 blog,user中,调用数据模型(专用,非M层),对数据进行处理. 5.回到逻辑控制类中,展现视图 $this->view->output( );

13. PHP没有持久层,每一次访问请求都是独立运行,建立的模型对象不能持久存在,无法跨访问复用.如果框架/应用的设计过于繁琐,每次装载/初始化都会浪费不少时间. 各层之间的耦合度尽量降到最低,尤其是业务模型和业务逻辑之间要尽量分离.以便日后修改或复用. PHP本身只有较少功能是抛出异常,大部份是抛出错误(Notice,warning,error),代码编写中应时常对应用环境的正确性做手工检查,不符合条件时手工抛出异常,并设置异常接收器统一处理 运用中需要注意的地方

14. 单入口模式 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/ Rewrite及pathinfo的好处:对搜索引擎友好,对用户更直观 访问模式

15. 数据库抽象层的作用 减少与具体数据库的底层接触,提供跨数据库平台的访问接口,以实现数据操作与数据库类型的无关性.方便数据库系统的迁移变更. PHP本身提供的抽象层 Pear::DB(php4),PDO(php5,6) 框架中引入的各种类Active Recode系统 目的：将数据库字段与映射到对象，不用关心具体的SQL语句，只需要操作数据对象及调用相关的方法即可实现数据的CRUD操作。 好处：模型化了数据库，快捷开发，是数据库抽象层的进一步进化。 缺点：对于复杂数据模型的处理较为无力，例如多表连查、子查询。 缺乏灵活性，比如只想要一列数据，却取出了整行。 与数据库字段名的耦合度太高。如通过配置改进，执行效率又打折扣。 难以应付复杂的Web环境。（多种数据库，分布式数据库，缓存系统介入） 数据库抽象层、Active recode

16. 为什么引入模板引擎 视图：在web开发中通常就是指前端页面。模板引擎的引入，是为了实现视图层的分离，降低视图与逻辑、模型部份的耦合度。使得前端页面与程序部份可以并行工发、轻松整合的工具 常见的模板引擎及特点 PHP中常用的模板引擎有 Smarty, SmartTemplate 其中smarty提供了强劲的功能，STE则非常轻巧。 两者的核心原理，都是将页面中的变量标签替换成通过assign方法注册的PHP运行变量，并将替换后的页面（“编译”后的页面文件）生成缓存保存在磁盘中。或者提供一定的逻辑控制功能供前端使用。这样即方便将程序和视图分离,使前端设计人员更着重于表现和数据,而不用关心程序上的流程. 缺点 初次加载模板时,因生成缓存,需要额外的处理开销和IO开销 之后加载模板时,会判断模板文件的最后修改时间是否大于生成的缓存文件时间,亦有一定的额外IO开销. 模板引擎

17. 尽量折分公用组件。 不要在视图中使用太多的控制语句 就以前的经验来看,简单的if,变量循环输出即已足够。 在视图中加入太多的控制语句会带来的问题，是对设计思想的破坏，因为它打乱了将视图层独立出来的最初目的，让前端的设计人员不得不过多的关注“程序”而非页面本身。要不然就得由程序员最终回头修改前端设计人员已经做好的模板文件。 更重要的一点时：如果在模板中引入太多的控制语句，那还不如直接在页面中写<?php ,因为PHP的本身就是模板引擎。无论哪种都快不过它。 所以,尽量将控制放在PHP程序体内,不要放到视图中去跑. 使用模板引擎的注意事项

18. LAMP架构下的加速系统 Memory disk Lighttpd,nginx,squid Db cache Apc,xcache memcached

19. WEB服务层 Nginx :自身支持反向代理,提供简单的负载均衡及从错机制,能很方便的搭建起web服务集群. Lighttpd:超轻量,合适搭建静态访问服务器 Squid:对动态内容亦能做缓存处理. PHP层 APC:缓存opcode,减少了扫描和编译阶段,但仍无法实现持久对象.纯脚本效率提高在200%--500%,应用场景下实测通常能提高效率一倍. XCACHE 数据层 共享内存 Memcache: Key=>Value 对形式的内存数据缓存服务.基于TCP连接.常用于缓存数据库查询结果.支持分布式. 缺点:关机即无,每次连接的时间开销大. 各级加速系统说明

20. 推荐的工具 Editplus+PHP XDEBUG+Eclipse PDT SmartTemplate Xdebug+ WinCacheGrind