First of all, the chosen structure is a compromise decision, that means that you'll have to deal and prioritize some aspects over others depending on your purpose. There are some grouping criterias you could follow, such as:
Functional Cohesion, I think that should be the strongest one in your design. Classes/files/resources with the same or similar functionality should be together
Component Hierarchy, Depending on the granularity level you choose, that means if you prefer fine-grained components vs coarse-grained, you would have more or less files/resources in one folder. This can be controlled using folder hierarchy and nesting.
Change, Some files are more likely to be changed than others, you have to keep this in mind in order to provide a folder hierarchy depending on the probability to be modified.
Extensibility, For a framework to be useful and adaptable to almost any scenario you have to provide the possibility to extend components and functions. Adding a folder for extensions (aka plugins) is a good idea.
There are lot of criterias you should use, but always keep in mind the KISS Principle. You can search for package management in books like The Unified Software Development Process (Ivar Jacobson et al.), I hope this could be helpful.
Since it is multi-purpose library devoted to solve versatile problems or provide interfaces for common features, it is better to have structure by subject which may be DataType/Technology/Language/Protocol etc. like so:
Http which is a protocol so your Http.request would be an interface to perform Http request
Html which is markup language, so Html.Form.UploadFile will provide developer with features to create upload file forms
JavaScript which is programming language, so your Javascript.JSON would solve problems of conversions from JSON to Arrays maybe
Ajax which is technology
XML which is markup language
DataType which is ... well, data type.
Notice, that status_codes remain under util in Http. Every sub-library can have its own util features like DataType lib may need datatype_cast_lib to know how to juggle with datatypes.
This way of library organization mostly resembles organzation of PECL
Good question, BTW! I asked the same question myself frequently. I've been organizing and reorganizing my directories structure for years. It really depends on project. I've adapted structure above corresponding to structure you've provided here.
$ ls
LICENSE.txt analysis core g11n security template tests
action console data net storage test util
我倾向于发现 Symfony 2 有点混乱/预测性较差，但这只是我自己的观点。）
I'd suggest that you look at how things are organized in two recent php 5.3 frameworks, Symfony2 and Lithium.
The core devs behind them were active (along with other major framework developers and php celebrities) in defining standard php 5.3 naming conventions so that their respective components could play with each other, Zend, and other libraries/frameworks that might follow the same conventions:
I would say a good place to start is to look at how other frameworks and/or libraries are doing it.
Personally I like the way the Zend Framework is organized, with a fairly flat namespace, having all major components in the Zend directory. When using the Zend MVC project structure, you get an added autoloader translating _ to / all classes are named like Zend_Form and put in a file called Form.php inside the Zend directory, so that when calling new Zend_Form - the autoloader looks for Zend/Form.php. Only the 'main' class is directly inside the Zend folder, any additional class files, like exceptions and abstract are put inside a Zend/Form folder, and classnames named like Zend_Form_Exception - which cause the autoloader to look for Zend/Form/Exception.php.
Another point, is to keep backend logic away from any public_html folder. E.G - only files that should be directly accessible for users should be in here (javascript, css, and your loader.php + .htaccess). Then have loader.php include the files it needs, typically one directory level up.
External libraries are usually treated as such, and separated from the rest of the code in a /lib, /library and/or /vendor folder to indicate that external authors are responsible for these classes.
I would say that it depends on how/if you use namepaces etc. Otherwise I would see a use for something like the ZendFramework directory layout (even though it's ugly as sin... hehe). Then I usually have a Corethat contains base functionality that all other parts might make use of like Array and String manipulation, Encryption/Decryption
Then I try to think of all subsequent folder as isolated parts/modules. Do I have a Jquery folder with a lot of JQuery helpers? Then that might be a good folder to add.
Does my JQuery require some HTML specifics that other "modules" might also use? Then that should go into Core. For instance my JQuery helpers might make use of JSON.
By always asking the question "Is this something that oter parts of my library will make use of and/or extend?" you will get a good idea if the functionality in question should be part of your Core or part of your specific library module.
发布评论
评论（7）
首先，所选择的结构是一个妥协的决定，这意味着您必须根据您的目的处理某些方面并将其优先于其他方面。您可以遵循一些分组标准，例如：
您应该使用很多标准，但请始终牢记KISS 原则。您可以在《统一软件开发流程》等书籍中搜索包管理 （Ivar Jacobson 等人），我希望这会有所帮助。
First of all, the chosen structure is a compromise decision, that means that you'll have to deal and prioritize some aspects over others depending on your purpose. There are some grouping criterias you could follow, such as:
There are lot of criterias you should use, but always keep in mind the KISS Principle. You can search for package management in books like The Unified Software Development Process (Ivar Jacobson et al.), I hope this could be helpful.
由于它是多用途库，致力于解决通用问题或为通用功能提供接口，因此最好按主题进行结构，可以是数据类型/技术/语言/协议等，如下所示
：顶部我们有：
Http.request将是执行 Http 请求的接口Html.Form.UploadFile将为开发人员提供创建上传文件表单请注意，
status_codes保留在Http中的util下。每个子库都可以有自己的 util 功能，例如 DataType lib 可能需要 datatype_cast_lib 来知道如何处理数据类型。这种库组织方式大多类似于 PECL 的组织，
顺便说一句，好问题！我自己也经常问同样的问题。多年来我一直在组织和重组我的目录结构。这确实取决于项目。我已经根据您在此处提供的结构调整了上面的结构。
Since it is multi-purpose library devoted to solve versatile problems or provide interfaces for common features, it is better to have structure by
subjectwhich may be DataType/Technology/Language/Protocol etc. like so:On top we have:
Http.requestwould be an interface to perform Http requestHtml.Form.UploadFilewill provide developer with features to create upload file formsNotice, that
status_codesremain underutilinHttp. Every sub-library can have its own util features likeDataTypelib may need datatype_cast_lib to know how to juggle with datatypes.This way of library organization mostly resembles organzation of PECL
Good question, BTW! I asked the same question myself frequently. I've been organizing and reorganizing my directories structure for years. It really depends on project. I've adapted structure above corresponding to structure you've provided here.
我建议你看看两个最近的 php 5.3 框架是如何组织的，Symfony2 和 锂。
他们背后的核心开发人员（以及其他主要框架开发人员和 php 名人）积极定义标准 php 5.3 命名约定，以便他们各自的组件可以彼此、Zend 以及可能遵循相同约定的其他库/框架一起使用：
http://groups.google.com/group/php-standards /web/php-coding-standard
在这两种情况下，包/库都是一等公民，并且在组织它们时两者遵循相似的模式。
尤其是 Lithium 核心，它本身就是一个库。它的组织方式如下：（
我倾向于发现 Symfony 2 有点混乱/预测性较差，但这只是我自己的观点。）
I'd suggest that you look at how things are organized in two recent php 5.3 frameworks, Symfony2 and Lithium.
The core devs behind them were active (along with other major framework developers and php celebrities) in defining standard php 5.3 naming conventions so that their respective components could play with each other, Zend, and other libraries/frameworks that might follow the same conventions:
http://groups.google.com/group/php-standards/web/php-coding-standard
In both cases, bundles/libraries are first-class citizens, and the two follow similar patterns when it comes to organizing them.
The Lithium core, in particular, is a library in its own right. It's organized like so:
(I tend to find Symfony 2 a bit messier/less predictive, but that's just my own opinion.)
无论结构如何，请与 PSR-0 兼容你将要使用。
我个人建议使用 PEAR2 目录结构 。
Please be PSR-0 compatible, whatever structure you're going to use.
I personally suggest using the PEAR2 directory structure .
我想说，一个好的起点是看看其他框架和/或库是如何做到这一点的。
就我个人而言，我喜欢 Zend Framework 的组织方式，具有相当平坦的命名空间，包含所有主要的Zend 目录中的组件。当使用 Zend MVC 项目结构时，您会获得一个添加的自动加载器，将 _ 翻译为 / 所有类都以
Zend_Form命名，并放入 Zend 目录中名为 Form.php 的文件中，以便在调用new Zend_Form- 自动加载器查找Zend/Form.php。只有“主”类直接位于 Zend 文件夹中，任何其他类文件（例如异常和抽象）都放在Zend/Form文件夹中，并且类名命名为Zend_Form_Exception- 这会导致自动加载器查找Zend/Form/Exception.php。另一点是让后端逻辑远离任何 public_html 文件夹。 EG - 只有用户可直接访问的文件才应位于此处（javascript、css 和 loader.php + .htaccess）。然后让 loader.php 包含它需要的文件，通常是上一层目录。
外部库通常被如此对待，并与 /lib、/library 和/或 /vendor 文件夹中的其余代码分开，以表明外部作者对这些类负责。
I would say a good place to start is to look at how other frameworks and/or libraries are doing it.
Personally I like the way the Zend Framework is organized, with a fairly flat namespace, having all major components in the Zend directory. When using the Zend MVC project structure, you get an added autoloader translating _ to / all classes are named like
Zend_Formand put in a file called Form.php inside the Zend directory, so that when callingnew Zend_Form- the autoloader looks forZend/Form.php. Only the 'main' class is directly inside the Zend folder, any additional class files, like exceptions and abstract are put inside aZend/Formfolder, and classnames named likeZend_Form_Exception- which cause the autoloader to look forZend/Form/Exception.php.Another point, is to keep backend logic away from any public_html folder. E.G - only files that should be directly accessible for users should be in here (javascript, css, and your loader.php + .htaccess). Then have loader.php include the files it needs, typically one directory level up.
External libraries are usually treated as such, and separated from the rest of the code in a /lib, /library and/or /vendor folder to indicate that external authors are responsible for these classes.
我想说这取决于你如何/是否使用命名空间等。否则我会看到像 ZendFramework 目录布局之类的东西的用途（尽管它很难看……呵呵）。然后我通常有一个核心，其中包含所有其他部分可能使用的基本功能，例如数组和字符串操作、加密/解密
然后我尝试将所有后续文件夹视为独立的部分/模块。我有一个包含大量 JQuery 助手的 Jquery 文件夹吗？那么这可能是一个很好的添加文件夹。
我的 JQuery 是否需要其他“模块”也可能使用的一些 HTML 细节？然后应该进入核心。例如，我的 JQuery 助手可能会使用 JSON。
如果它是 JQUery 特定的，那么它应该位于 JQuery 下。
总是问这样的问题：“我的库的其他部分会使用和/或扩展这个东西吗？”您会很清楚所讨论的功能是否应该是您的核心的一部分或特定库模块的一部分。
I would say that it depends on how/if you use namepaces etc. Otherwise I would see a use for something like the ZendFramework directory layout (even though it's ugly as sin... hehe). Then I usually have a
Corethat contains base functionality that all other parts might make use of like Array and String manipulation, Encryption/DecryptionThen I try to think of all subsequent folder as isolated parts/modules. Do I have a Jquery folder with a lot of JQuery helpers? Then that might be a good folder to add.
Does my JQuery require some HTML specifics that other "modules" might also use? Then that should go into Core. For instance my JQuery helpers might make use of JSON.
If it's JQUery specific it should recide under JQuery.
By always asking the question "Is this something that oter parts of my library will make use of and/or extend?" you will get a good idea if the functionality in question should be part of your Core or part of your specific library module.
来源： http://framework.zend.com/manual/en/project -struct.project.html
source: http://framework.zend.com/manual/en/project-structure.project.html