Zend Архитектура проекта

В настоящее время я использую Zend 3 для проекта (или ряда проектов). Чтобы избежать нескольких vendor папок для каждого проекта, я бы хотел иметь одну папку с vendor на уровне корня, с которой выполняется каждый проект.Zend Архитектура проекта

В моем файле приложения /public/index.php, я изменил эту строку:

include __DIR__ . '/../vendor/autoload.php';

к этому:

include __DIR__ . '/../../shared/vendor/autoload.php';

Когда я сделал это, я видел эту ошибку:

Fatal error: Uncaught exception 'Zend\ModuleManager\Exception\RuntimeException with message Module (Application) could not be initialized. in C:\Users\b28934\Documents\server\UwAmp\www\zf3\app\vendor\zendframework\zend-modulemanager\src\ModuleManager.php on line 203"

Какие-либо предложения? Есть ли что-то, что мне не хватает в моем файле composer.json?

источник

2017-02-16 Olu Carter

Прежде всего, нет необходимости иметь только одну папку vendor для всех проектов. В настоящее время пространство на диске дешево. Я определенно не вижу причин.
По дизайну каждый проект композитора имеет свою собственную папку vendor, потому что он потерпит неудачу, если у вас есть 2 проекта, для которых требуется один и тот же пакет, но в разные версии.

Предлагаю хранить его просто. Держите его так, как будто он разработан умными людьми. И не пытайтесь испортить это без причины.

источник

2017-02-16 11:01:05

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

№ Время придет, когда вам понадобится пакет 'foo/A' в проекте 1 и пакет' foo/B' в проекте 2. И если 'foo/A' зависит от' foo/C' версии 1 и 'foo/B 'зависит от' foo/C' version 2, тогда все испорчено. Я видел некоторых * людей, которые думали так же, как вы, и каждый раз, когда эти люди заканчивались запутанной настройкой и нуждались в возврате к одному проекту одной философии папок поставщика. Это хорошо разработанный механизм. Легче копировать 'composer.json' и запускать обновление для каждого проекта и сохранять их независимыми. В случае возникновения каких-либо проблем вы можете держать их в разных зависимостях. –

ответ

Смежные вопросы