Как мне организовать структуру каталогов библиотеки общего назначения?

Ответ 1

Прежде всего, выбранная структура является компромиссным решением, а это означает, что вам придется решать и определять приоритеты некоторых аспектов над другими в зависимости от вашей цели. Существуют следующие критерии группировки, например:

• Функциональная сплоченность, я думаю, это должно быть самым сильным в вашем дизайне. Классы/файлы/ресурсы с одинаковой или сходной функциональностью должны быть вместе
• Иерархия компонентов. В зависимости от выбранного уровня детализации это означает, что если вы предпочитаете мелкозернистые компоненты и грубые, у вас будет больше или меньше файлов/ресурсов в одной папке. Это можно контролировать с помощью иерархии папок и вложенности.
• Изменить. Некоторые файлы с большей вероятностью будут изменены, чем другие, вы должны помнить об этом, чтобы обеспечить иерархию папок в зависимости от вероятности изменения.
• Расширяемость. Чтобы среда была полезной и адаптируемой практически к любому сценарию, вы должны предоставить возможность расширения компонентов и функций. Добавление папки для расширений (aka plugins) - хорошая идея.

Существует много критериев, которые вы должны использовать, но всегда помните Принцип KISS. Вы можете искать управление пакетами в книгах, например Процесс разработки унифицированного программного обеспечения (Ivar Jacobson и др.), Я надеюсь это может быть полезно.

Ответ 2

Поскольку это многоцелевая библиотека, предназначенная для решения универсальных задач или предоставления интерфейсов для общих функций, лучше иметь структуру subject, которая может быть DataType/Technology/Language/Protocol и т.д. так:

+ Http
  - request
  - response
  + util
    - status_codes
+ Html
  - Validator
  + Form
    - UploadFile
  + Tag
+ JavaScript
  - JSON
+ Ajax
+ XML
  - Reader
  - Writer
  - Parser
+ DataType
  - Array
  - Integer
  - String
  - Double
  - Float
  + util
    - datatypes_cast_lib

В верхней части мы имеем:

• Http, который является протоколом, поэтому ваш Http.request будет интерфейсом для выполнения запроса Http
• Html, который является языком разметки, поэтому Html.Form.UploadFile предоставит разработчику функции для создания форматов загружаемых файлов.
• JavaScript, который является языком программирования, поэтому ваш Javascript.JSON решит проблемы конверсий из JSON в массивы, возможно,
• Ajax, который является технологией
• XML, который является языком разметки
• DataType, который... ну, тип данных.

Обратите внимание, что status_codes остается под util в Http. Каждая подбиблиотека может иметь свои собственные функции использования, такие как DataType lib может нуждаться в datatype_cast_lib, чтобы знать, как жонглировать с типами данных.

Этот способ организации библиотеки в основном напоминает организацию PECL

Хороший вопрос, кстати! Я задавал тот же вопрос сам. Я много лет организую и реорганизую свою структуру каталогов. Это действительно зависит от проекта. Я адаптировал структуру выше соответствующей структуре, которую вы предоставили здесь.

Ответ 3

Я бы предположил, что вы смотрите, как все организовано в двух последних фреймах php 5.3, Symfony2 и Литий.

Основные разработчики позади них были активны (наряду с другими крупными разработчиками рамок и знаменитостями php) в определении стандартных соглашений об именах php 5.3, чтобы их соответствующие компоненты могли играть друг с другом, Zend и другие библиотеки/фреймворки, которые могли бы следовать одинаковые соглашения:

http://groups.google.com/group/php-standards/web/php-coding-standard

В обоих случаях связки/библиотеки являются первоклассными гражданами, и они следуют аналогичным шаблонам, когда дело доходит до их организации.

Литиевое ядро, в частности, является собственной библиотекой. Он организован так:

$ ls
LICENSE.txt analysis    core        g11n        security    template    tests
action      console     data        net         storage     test        util

(Я, как правило, считаю Symfony 2 более беспорядочным/менее прогностическим, но это только мое собственное мнение.)

Ответ 4

Пожалуйста, PSR-0 совместим, какую бы структуру вы ни использовали.

Я лично предлагаю использовать структуру каталогов PEAR2.

Ответ 5

Я бы сказал, что хорошее место для начала - посмотреть, как это делают другие фреймворки и/или библиотеки.

Лично мне нравится, как Zend Framework организован с довольно плоским пространством имен, имеющим все основные компоненты в каталоге Zend. При использовании структуры проекта Zend MVC вы получаете добавленный автозагрузчик, переводящий _ в/все классы, называются как Zend_Form и помещаются в файл с именем Form.php внутри каталога Zend, так что при вызове new Zend_Form - просмотр автозагрузчика для Zend/Form.php. Только класс "main" находится непосредственно внутри папки Zend, любые дополнительные файлы классов, такие как исключения и абстрактные, помещаются в папку Zend/Form и имена классов, названные как Zend_Form_Exception -, которые заставляют автозагрузчик искать Zend/Form/Exception.php.

Еще один момент - сохранить бэкэнд-логику от любой папки public_html. E.G - здесь должны быть только файлы, которые должны быть доступны для пользователей (javascript, css и ваш loader.php +.htaccess). Затем добавьте loader.php файлы, которые ему нужны, обычно один уровень на уровне выше.

Внешние библиотеки обычно рассматриваются как таковые и отделяются от остальной части кода в папке /lib,/library и/или/vendor, чтобы указать, что внешние авторы несут ответственность за эти классы.

Ответ 6

Я бы сказал, что это зависит от того, как/если вы используете пространства имен и т.д. В противном случае я увижу использование чего-то вроде макета каталога ZendFramework (хотя это уродливо, как грех... хе-хе). Тогда у меня обычно есть Core, который содержит базовую функциональность, которую могут использовать все другие части, такие как манипуляции с массивами и строками, шифрование/дешифрование

+ Core
 - Array
 - String
 + Encryption
   - MD5
   - SHA1
   ...

Затем я пытаюсь думать обо всех последующих папках как отдельные части/модули. У меня есть папка JQuery с большим количеством помощников JQuery? Тогда это может быть хорошая папка для добавления.

+ Core
 - Array
 - String
 + Encryption
   - MD5
   - SHA1
   ...
+JQuery

Является ли в моем JQuery некоторыми спецификациями HTML, которые могут использовать и другие "модули"? Тогда это должно пойти в Core. Например, мои помощники JQuery могут использовать JSON.

+ Core
 - Array
 - String
 + Encryption
   - MD5
   - SHA1
   ...
 + Encoding
   - JSON
+JQuery

Если это спецификация JQUery, она должна быть указана в JQuery.

+ Core
 - Array
 - String
 + Encryption
   - MD5
   - SHA1
   ...
+ JQuery
  - Datepicker

Всегда задавая вопрос: "Является ли это тем, что другие части моей библиотеки будут использовать и/или расширяться?" вы получите хорошую идею, если рассматриваемая функциональность должна быть частью вашего Core или части вашего конкретного библиотечного модуля.

Ответ 7

<project name>/
    application/
        configs/
            application.ini
        controllers/
            helpers/
        forms/
        layouts/
            filters/
            helpers/
            scripts/
        models/
        modules/
        services/
        views/
            filters/
            helpers/
            scripts/
        Bootstrap.php
    data/
        cache/
        indexes/
        locales/
        logs/
        sessions/
        uploads/
    docs/
    library/
    public/
        css/
        images/
        js/
        .htaccess
        index.php
    scripts/
        jobs/
        build/
    temp/
    tests/

источник: http://framework.zend.com/manual/en/project-structure.project.html