PHP应用目录结构设计

1 概述... 15

2 目录结构类型... 15

2.1 古典型 (类Unix/Linux) 15

2.2 古典扩展型... 17

2.3 古典扩展嵌入型... 18

2.4 常规型结构... 19

2.5 常规模块型结构... 21

3 命名约定... 22

本文归纳和阐述了动态网站应用中常用的集中文件组织结构，通过对每种结构的优点和缺点进行介绍，帮助开发者在开始一个新项目前有一个好的开始。本文归纳的几种层级结构是在集合众多意见和建议基础之上得到的，同时通过给每个结构命名，也便于开发者比较他们的优劣。

1 概述

以下目录结构的定义是从各种网站应用中总结出来的，并按一定顺序排列。

l        古典型结构(类Unix/Linux)

l        古典扩展型结构

l        古典扩展嵌入型结构

l        常规型结构

l        常规模块型结构

另外，本文列出的目录名，比如“/var”、“/tmp”、“/temporary”等，都假定有唯一的前缀，以避免一些安全问题。例如，目录“/tmp”可能实际表示目录“/my/permission/protected/tmp”，而不是大多数UNIX系统中共享的“/tmp”目录。像其他顶级目录一样，类似“/application”这样的目录也有一个跟开发环境有关的前缀，比如/home/me/myZFApp/application。

2 目录结构类型

2.1 古典型 (类Unix/Linux)

顶层划分为2个目录，分别用来保存网站可读文件（比如图片、javascript脚本或css文件）和应用程序文件，这种风格模拟了Unix/Linux操作系统的目录结构，比较符合Unix/Linux风格爱好者的口味。

/application
    /etc
    /lib
        /Zend
        /(other libraries)
    /usr
        /controllers
        /models
        /views
    /var
        /sessions
        /cache
        /view_compiles
/htdocs
    /images
    /scrīpts
    /styles

l       优点 

n        独立的、与应用相关的文件放置于一个地方，与网站可读文件分开，安全性较高；

n        类库文件存放于本地，而不是服务器端；

n        这种布局尤其适合于models、views和controllers相互关联的情况；

l       缺点

n        不熟悉Unix/Linux的人会对这种命名风格感觉神秘；

n        对于多个models、views和controllers的组合，如果他们互不相关，比如与博客相关的代码和与投票相关的代码，把他们按组分别放置于一个目录就不太合适。

2.2 古典扩展型

/application

    /config

    /library

        /Zend

        /(other libraries)

    /user

        /controller

        /model

        /view

    /variable

        /sessions

        /cache

        /view_compiles

/htdocs

    /images

    /scrīpts

    /styles

    index.php

l       优点

n        同古典型结构的优点；

n        把Unix/Linux风格的简短命名如：lib、usr和var，用其全称表示，对不熟悉Unix/Linux风格的人会更清晰；

l       缺点

n        同古典型结构的缺点，除了命名风格这一条。

2.3 古典扩展嵌入型

在某些情况下，把应用相关的文件放置在网站可读目录之外会比较困难，比如你使用的是一个租用的虚拟主机。对于这种情况，位于网站可读目录下的应用文件，应尽可能通过.htaccess文件或其他保护机制保护。

安全提示：把应用相关文件放置在网站可读目录，会带来些潜在的安全威胁，比如网站敏感信息被暴露，或服务器被暴露给黑客攻击者。

/htdocs

    /application

        /config

        /library

            /Zend

            /(other libraries)

        /user

            /controller

            /model

            /view

        /variable

            /sessions

            /cache

            /view_compiles

        .htaccess (deny from all)

    /images

    /scrīpts

    /styles

    index.php

l       优点

n        如果开发者只能访问到如htdoc这样的网站可能目录，这种结构就比较适用；

l       缺点

n        如果没有精心配置，这种结构可能会带来安全问题；

n        不能使用到/application/的映射，因为他实际存在与文件系统中。

2.4 常规型结构

/application

    /config

    /controllers

    /models

    /views

/htdocs

    /images

    /scrīpts

    /styles

    index.php

/library

    /Zend

    /(other libraries)

/tmp

    /sessions

    /cache

    /view_compiles

l       优点

n        除了用户写的类库代码，应用相关的代码(比如用于同一个域的model、controllers和views)位于一个特定目录；

n        类库在系统中是全局安装的（就像PEAR一样）；

n        古典型结构把相关的代码集中放置于一个顶层目录，而常规型结构与此恰恰相反，他创建了多个顶层目录：

u      Application：放置与应用直接相关的代码；

u      Library：放置类库，这些代码实现某些一定的通用功能，而并不与应用密切相关；

u      Tmp：或者variable目录，是应用程序使用文件系统并生成一些临时文件的地方，比如存放session文件、cache文件或者视图的临时编译文件等；

n        如果条件允许，这也是Zend Framework推荐使用的目录结构：

u      使用最通用或推荐的目录结构，将显著提高开发效率。

l       缺点

n        顶层目录结构较多。

n        改造成嵌入结构比较困难(例如把顶层目录都移入到网站可读的htdocs目录中)，因为每个具体目录都有设置其安全性。

n        某些应用可能需要自定义类库或扩展类库，这种情况下，不容易区分用户自定义类库和第三方类库。

2.5 常规模块型结构

对于这种结构，用于某一特定模块的models、views和controllers会打包放在一个目录下。

/application

    /config (optional)

    /(module 1)

        /config (optional as needed)

        /controllers

        /models

        /views

    /(module 2)

        /controllers

        /models

        /views

    /(module n)

        /controllers

        /models

        /views

/htdocs

    /images

    /scrīpts

    /styles

    index.php

/library

    /Zend

    /(other libraries)

/tmp

    /sessions

    /cache

    /view_compiles

l       优点

n        同常规型结构

n        可以对不相关的应用模块分别打包，比如一个拥有博客、投票系统、交易系统的web网站。

l       缺点

n        同常规型结构

3 命名约定

名字	可替代名字
htdocs	www、public_html或inetpub
images	img
scripts	js或者javascrīpt
styles	css