Какие преимущества я получу, если выберу модуль вместо компонента MXML?
Модули и компоненты - это две разные вещи. Модуль похож на DLL в Windows или файл Jar в Java. В этом он содержит часть кода, которую можно загружать и выгружать во время выполнения. Таким образом, модули могут содержать один или несколько компонентов MXML. Они не заменяют использование компонентов MXML. Вы по-прежнему будете создавать свое приложение, используя MXML, независимо от того, используете ли вы модули или нет. К сожалению, модули упакованы множеством других «функций», которые не делают работу с ними такой простой, как, скажем, файл Jar в Java.
У них есть свои плюсы и минусы. Вы можете уменьшить объем используемой памяти, загружая и выгружая код, но в наши дни размер байт-кода НЕ является основной причиной раздувания памяти. Это на самом деле, как операторы используют кучу, что приводит к увеличению памяти. Вы можете легко обмениваться кодом между проектами без использования модулей, используя SWC, или просто делиться кодом через общие проекты SVN.
Другие недостатки модулей - это создание дополнительных границ в вашей программе. Ссылка на объекты внутри модуля может быть проблемой. Объекты, которые используют Модуль, могут ссылаться на объекты, определенные в модуле, но не наоборот, поэтому, если вы не будете осторожны в том, как вы организовываете свои модули, вы можете в итоге сбросить код в модуль, который там не принадлежит.
Я бы начал с использования модулей, а не рефакторинга, если бы у меня была явная потребность в них. Модули будут только увеличивать накладные расходы на разработку ваших накладных расходов, как только вы начнете их использовать.
Каков предпочтительный и лучший способ разработки приложения Flex?
MVC или MVCS. Служба контроллера представления модели или контроллера представления модели. Некоторые люди зацикливаются на командах лучше, чем на контроллере, но на самом деле команда - это контроллер только с одним методом контроллера. Это дегенеративный контроллер. Мне нравятся контроллеры, потому что очень легко добавить новую команду в контроллер, просто добавив метод, а не целый новый класс, как диктуют команды. Кроме того, контроллер позволяет группировать общие функции вместе для экрана, подсистемы и т. Д. Вы можете выбрать, насколько мелкие детали вам нужны для ваших контроллеров. Также контроллеры могут быть легко разделены, когда они становятся слишком большими.
MVCS легко сделать без фреймворка, но использование фреймворка - хорошая идея, так как оно помогает вашей команде понять, как создается приложение. Также программное обеспечение с открытым исходным кодом делает довольно хорошую работу по документированию фреймворка, чтобы вам не приходилось отвечать на многие вопросы низкого уровня о вашей фреймворке. Хороший выбор - Swiz, Parsley или Mate. Тем не менее, большинство переезжает в Swiz или Parsley сейчас вдали от Mate и Caringorm Caringorm будет Петрушка в будущем FYI.
Шаблон презентационной модели поможет вам, когда вы захотите провести больше модульного тестирования, поэтому посмотрите, как это работает, будет полезно для вашего исследования. Хотя я больше тестирую контроллер и модель и делаю либо традиционный QA для View, либо интеграционное тестирование. QA намного проще.
Поскольку приложение будет взаимодействовать с Backend, нужно ли нам сделать интерфейс более сложным?
Вам придется принять решение о том, какую сложность вы хотите, чтобы передний конец обрабатывал. Фоновая обработка является слабым местом в Flex, поэтому иногда имеет смысл перейти к бэкэнду. Я думаю, вы будете удивлены тем, сколько работы уходит на передний план. Flex - это RIA, что означает, что во Front-интерфейсе будет выполняться больше работы, это нормально, но вам придется решить, что и где делать.
Мое предложение заключается в том, что интерфейсные вызовы простых служб на бэкэнде используют JSON или AMF (Blaze DS). Если вам нужно что-то вроде проталкивания сервера, вы можете использовать ActiveMQ, так как он имеет разъемы для Flex.
Существует ли какая-либо архитектура на основе модулей для предварительного просмотра примера или какой-либо пример, в котором они определили хорошую архитектуру.
Модули и архитектура находятся под влиянием друг друга, но использование модулей не означает, что у вас есть четко определенная архитектура. У вас просто есть сегменты, в которые вы выгружаете код. Модули не будут определять обязанности или организацию в вашем коде, что и делает архитектура. Как я уже сказал, модули похожи на библиотеки DLL, и вы не видите архитектуру на основе библиотек DLL, которую можно взять с полки. Фреймворки, такие как Swiz, помогут определить вашу архитектуру больше, чем модули. Я бы сказал, перестаньте фокусироваться на модулях и посмотрите на архитектуру, а затем посмотрите, нужны ли они вам.