Comments 5
Это должно считаться истиной в последней инстанции?
Мне кажется, что ответ прост: структура папок проекта отражает структуру зависимостей частей кода друг от друга — более общие и базовые вещи на более верхнем уровне, более специфические — на более нижнем. В случае сомнения — кладём на один уровень. (в случае очень большого проекта, структура папок начинает отражать структуру организации, что не случайно)
Да и это зависит от языка программирования. Тот же Python обладает достаточно мощной системой импорта, которая позволяет сделать почти всё, что угодно, даже циклические зависимости (что очень плохо и чего нужно избегать). Хорошая статья на тему. И ещё одна.
Если код написан хорошо, то его работоспособность не должна зависеть от расположения в папках (а конкретизация отношений происходит в каком-нибудь модуле самого общего уровня) и в итоге такую структуру сравнительно легко менять.
Самая большая проблема иерархии каталогов в том, что она (а также логика импорта и зависимостей в большинстве языков программирования) слишком похожа на одну из самых больших проблем ООП: наследование (которого также следует избегать). Проблема наследования в том, что оно накладывает одну единственную структуру на набор сущностей, тогда как очень часто мы оперируем в рамках нескольких несовместимых структур параллельно.
Например: с одной стороны хорошо, когда все шаблоны лежат в одной папке — мы можем настроить для неё отдельные права доступа, кэширование, отдавать с другого сервера, и т.д., и т.д. Если мы используем хороший движок шаблонов, то мы можем сделать базовые шаблоны, которые будут расширяться более специфичными шаблонами. Мы можем «подготавливать» шаблоны к использованию (например, в Go необходимо явно вызывать ParseFile, которая подгружает шаблон из файла в пустой шаблон, перед использованием).
С другой стороны шаблон тесно связан с V и C в аббревиатуре MVC. Если поменялась модель данных, должны поменяться обработчики и должен поменяться шаблон. А если части крупного веб-проекта делаются разными людьми, то это тем более адекватно, даже с точки зрения систем контроля версий (любопытно, как эти папко-ориентированные программы меняют наш подход к структурированию файлов и каталогов).
Что выбрать? Разве здесь может быть окончательный ответ?
Мне кажется, что ответ прост: структура папок проекта отражает структуру зависимостей частей кода друг от друга — более общие и базовые вещи на более верхнем уровне, более специфические — на более нижнем. В случае сомнения — кладём на один уровень. (в случае очень большого проекта, структура папок начинает отражать структуру организации, что не случайно)
Да и это зависит от языка программирования. Тот же Python обладает достаточно мощной системой импорта, которая позволяет сделать почти всё, что угодно, даже циклические зависимости (что очень плохо и чего нужно избегать). Хорошая статья на тему. И ещё одна.
Если код написан хорошо, то его работоспособность не должна зависеть от расположения в папках (а конкретизация отношений происходит в каком-нибудь модуле самого общего уровня) и в итоге такую структуру сравнительно легко менять.
Самая большая проблема иерархии каталогов в том, что она (а также логика импорта и зависимостей в большинстве языков программирования) слишком похожа на одну из самых больших проблем ООП: наследование (которого также следует избегать). Проблема наследования в том, что оно накладывает одну единственную структуру на набор сущностей, тогда как очень часто мы оперируем в рамках нескольких несовместимых структур параллельно.
Например: с одной стороны хорошо, когда все шаблоны лежат в одной папке — мы можем настроить для неё отдельные права доступа, кэширование, отдавать с другого сервера, и т.д., и т.д. Если мы используем хороший движок шаблонов, то мы можем сделать базовые шаблоны, которые будут расширяться более специфичными шаблонами. Мы можем «подготавливать» шаблоны к использованию (например, в Go необходимо явно вызывать ParseFile, которая подгружает шаблон из файла в пустой шаблон, перед использованием).
С другой стороны шаблон тесно связан с V и C в аббревиатуре MVC. Если поменялась модель данных, должны поменяться обработчики и должен поменяться шаблон. А если части крупного веб-проекта делаются разными людьми, то это тем более адекватно, даже с точки зрения систем контроля версий (любопытно, как эти папко-ориентированные программы меняют наш подход к структурированию файлов и каталогов).
Что выбрать? Разве здесь может быть окончательный ответ?
MVC не единственный шаблон проектирования. Бесспорно, что нужно применять тот шаблон, который наилучшим образом подходит к проекту. Указанная в статье структура по большей части опирается на бизнес-логику проекта и выделение независимых частей в проекте. Такая структура позволила с лёгкостью переносить код, компоненты, целые каталоги между проектами без ущерба основному функционалу проектов. Обсуждение плюсов разработки по шаблону MVC достаточно хорошо описано в других статьях https://habr.com/search/?q=mvc
UFO just landed and posted this here
Sign up to leave a comment.
Структура каталогов для проекта (в частности на Flask)