Архитектура проекта Flex?
Что лучший способ состоит в том, чтобы организовать модули функциональности в проекте гибкого провода? Я видел, что некоторые люди поместили все модули в одну стопку представления, и таким образом, интерфейс приложения является только загрузкой однажды, но когда приложение станет больше, скомпилированный swf целого будет очень большим. Если мы помещаем swfs в различные страницы, мы передаем параметры запроса через Запрос HTTP, мы потеряли преимущества от гибкого провода услуги RPC, медленная загрузка, и мы не видим немного выше по сравнению с php, asp, jsp..., что лучшая практика должна организовать архитектуру фронтэнда?
3 ответа
Это сложный вопрос, и он зависит от вашего приложения. Я боролся с этим довольно долго, поэтому мне интересно увидеть и другие подходы.
Что касается архитектуры, я обычно создать приложение "фрейм", которое позаботится о загрузке модулей и, как правило, также их отображении. Этот фрейм обычно также решает такие проблемы, как аутентификация. Не так важно, является ли это стеком просмотра или другим решением.Но обычно вы не хотите, чтобы все было упаковано в один гигантский SWF-файл, потому что проигрывателю Flash нужно будет загрузить все это перед фактическим отображением чего-либо.
Связанная проблема, которая обычно возникает при проектировании приложений, заключается в том, как обрабатывать «навигацию» в результирующем приложении. Обычно я создаю какое-то событие навигации, которое частично обрабатывается фреймом (загрузочными модулями) и / или фактическими модулями. Но опять же, это только мое понимание, мне любопытно услышать другие подходы.
Модули загружаются по запросу. Таким образом, размер родительского swf не должен зависеть от количества модулей. Однако размер используемой памяти будет увеличиваться при загрузке модулей - если это проблема, вы можете попытаться выгрузить их (непростая задача, но вы можете это сделать). Так что я бы сохранил подход стека представлений.
Некоторое время назад я совместно создал фреймворк для больших приложений Flex под названием Anvil. Проект довольно мертв, но архитектурные шаблоны, которые мы использовали в Anvil, по-прежнему актуальны для больших приложений. Вы можете прочитать больше об архитектуре Anvil здесь . Вы также можете проверить UcompOS.