Приложение многостраничной базы данных в Flash Builder - как получить доступ / вызвать разные экраны?

Question

Я пытаюсь создать свое первое приложение в реальном мире.Это приложение, управляемое базой данных (через веб-службы) в Flash Builder 4.

Приложение будет иметь более 30+ различных экранов ввода данных, экранов списков, экранов поиска и т. Д., Которые все используют различные веб-сервисы.

Очевидно, я хочу разделить это так, чтобы оно было управляемым по мере роста приложения, и чтобы приложение было максимально быстрым (начальная загрузка может быть медленной, если она должна загрузить все элементы, но я хочу, чтобы это былобыстро, когда пользователь «в» приложении).

Подход, который у меня был до сих пор, заключался в том, чтобы иметь мое основное приложение (называемое макетом), а затем иметь ViewStack с каждым из различных экранов на нем.Это хорошо работает, однако это означает, что каждый раз, когда я добавляю новый экран, нужно поддерживать немало кода (информация об этом здесь: Замена компонента MXML в приложении на другой компонент - возможно? )

Каждая группа форм связана, поэтому в области «клиенты» приложения есть форма ввода данных, несколько форм списка.Мне нужно передать параметры при загрузке.то есть.«Загрузить форму ввода данных с идентификатором 123».

На данный момент у меня есть компонент для каждой формы, т.е.ClientForm и ClientList.Это хороший подход?Стоит ли вместо этого использовать модули?

Является ли ViewStack эффективным способом сделать это?

Answer 1

Если бы я разработал такое приложение, я бы отказался от просмотра стеков и принял бы состояния. Они стали намного лучше, так как Flex 2/3 заявляет. Основное преимущество состояний по сравнению со стеками представлений заключается в том, что у вас нет дополнительных контейнеров / держателей для ваших дочерних контейнеров. Еще одним преимуществом является возможность переключения состояний с использованием строковых идентификаторов, которые вы можете легко передавать с вашими событиями без необходимости использовать какое-либо отображение между строковыми идентификаторами и представлениями. Просто используя те же строки, что и имена состояний. Так что он будет слабосвязанным и довольно модульным.

Еще один совет - попытайтесь разбить ваше приложение на небольшие независимые компоненты / классы, насколько это возможно. Попробуйте изолировать все обращения к серверу на отдельные действия / команды. Вы можете использовать некоторые архитектурные рамки для этого, если хотите, (например, Mate, Parsley или что-то еще; просто избегайте Cairngorm или PureMVC).

Преформа, анализирующая ваши экраны и звонки. Есть ли конечное количество экранов и звонков? Возможно ли их добавить в будущем? Как часто они будут добавлены? В случае конечного числа экранов с редкой возможностью добавления одного / двух экранов в будущем вы можете поместить все свои состояния в один компонент MXML, извлекая сами представления в отдельные компоненты, используя модель событий для получения отзывов о них с помощью пользовательских событий. Если количество представлений довольно велико, вы можете сформировать некоторую иерархию состояний, группирующих состояния представлений по отдельным подкомпонентам, чтобы иметь читаемый (и обслуживаемый) код.

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

Я надеюсь, что перечисленные выше указания могут послужить хорошей отправной точкой для планирования вашей заявки. Удачи!