Я столкнулся с некоторыми похожими проблемами в большой кодовой базе, за которую взял на себя ответственность, и я работал над двумя основными целями:
- Сделайте представления настолько маленькими, насколько это разумно, и используйте их повторно через композицию
- Разделение кода, специфичного для представления, и внутренних функций (обработка данных, запросы на стороне сервера и т. Д.)
Многоразовые просмотры
При создании представления, которое является надмножеством другого (возможно, администратора и пользователя), я пытался создать отдельные представления, которые состоят из аналогичных компонентов. Представление Admin может «обернуть» представление User и добавить любую необходимую ему функциональность. Когда это работает (что не всегда), это означает, что мне не нужно обрабатывать слишком много состояний, потому что одно представление просто является оберткой вокруг другого.
Когда перенос не работает, я пытаюсь найти общие функциональные возможности для построения каждого представления отдельно.
Например: администраторы и пользователи могут иметь элементы управления входом, но не гости. Это будет отдельный компонент MXML, который я затем включу в представления Admin и User. Другие элементы управления, общие для всех 3, могут быть другим компонентом MXML, который будет включен во все 3 представления. Этот метод немного больше работы, и вы должны быть осторожны, чтобы не сходить с ума (например, заканчивая одним файлом MXML на контейнер / элемент управления Flex), но это означает, что я могу повторно использовать определенные визуальные компоненты без копирования и вставки. Это также означает, что каждый вид может настроить их отображение, если это необходимо.
Я использовал наследование в своих представлениях, но только когда они явно имели отношения IS-A и изменение кода в одном из них потребовало бы изменения в другом. Я также использовал состояния для управления небольшими изменениями в одном представлении, но я стараюсь ограничить их одним или двумя состояниями, чтобы, как вы упомянули, они не становились ужасно громоздкими.
Отделенная функциональность
Я использовал Presenters , чтобы помочь отделить связь представления с его данными. Каждое представление имеет объект презентатора, к которому он привязывает свои данные. Это сохраняет тэг SCRIPT в представлении очень маленьким, поскольку представлению нужно только знать, какие данные в презентаторе нужно связать и какие методы вызывать при вызове его элементов управления.
Эти докладчики также могут быть разделены между представлениями.
Вот пример того, как это может выглядеть в проекте входа пользователя / администратора:
------------------
| User View | ----------------------- ---------------
| Login Button |------- | Presenter | | Model/ |
------------------ | Login Click Handler |-------| Controller/ |
----------------------- | ... |
| ---------------
------------------ |
| Admin View | |
| Login Button |------------------
------------------
Представления «Пользователь» и «Администратор» довольно просты: они представляют собой совокупность визуальных элементов управления (HBox, Slider, Buttons и т. Д.), Написанных на MXML с использованием как можно меньшего количества кода ActionScript (хотя они обычно есть). Каждому из них предоставляется объект презентатора (написанный на ActionScript и внедренный платформой), который имеет привязываемые свойства / данные и функции, которые может вызывать представление. Презентаторы также в некотором роде могут передавать изменения свойств / данных в серверную часть приложения (например, через контроллеры, события и т. Д.). Они передают любые обновления данных обратно в представление через их привязываемые свойства / данные.
Чтобы облегчить это, я использовал Parsley , хотя есть ряд других платформ, которые также помогут с этим типом развязки.
Это делает создание новых представлений довольно простым, так как функциональные возможности в основном написаны. Если он не написан, я пишу нового докладчика, специфичного для создаваемого мною представления, или пытаюсь повторно использовать существующий через наследование или композицию.
Я думаю, что это немного облегчит переход на Flex 4 (что я очень скоро заставляю делать наш проект): все основные изменения, связанные с просмотром, должны быть ограничены файлами MXML, а докладчики должны измениться. очень мало. Я не буду гоняться за визуальными компонентами, которые нужно менять где-либо, кроме вида.
Вот две хорошие статьи, которые также обсуждают разбивку взглядов: