Лучшие практики для больших приложений Flex?

Question

Я нахожусь в середине создания довольно большого приложения flex, и со временем он начинает опускаться к неподдерживаемости.

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

Часть проблемы, похоже, состоит в том, что у меня есть около 30 объектов, наследуемых от одного абстрактного объекта типа суперкласса. Все дочерние объекты имеют как логический компонент, так и компонент ui, которые тесно интегрированы друг с другом. Объект суперкласса имеет около 60 общих методов и свойств, большинство из которых можно переопределить в любом из дочерних классов, некоторые из которых должны быть переопределены во всех дочерних классах.

Чтобы добавить к сложности, они должны связываться между собой, и это обычно происходит через объект-контейнер, в котором они находятся. Кроме того, основной проект должен создавать объекты ценности из них, чтобы их можно было отправить в FlourineFX бэкэнд для хранения и дополнительную логику аутентификации/авторизации.

Я создал гораздо большие проекты на языках от старых MS BASIC (pre VB), Ada, VB (от 3 до .Net 1), C++ и C# без этой проблемы. (ну, старый VB имел тенденцию к этой проблеме из-за такой же тесной интеграции между UI и логикой) Итак, есть ли что-то, чего я не вижу, или есть ли какие-либо лучшие практики, которые я могу реализовать? (даже если это означает переписывание целых строк кода)

И да, это может быть расширение до this.

Answer 1

Используете ли вы какие-либо реализации фреймворка в этом проекте? Рамка поможет сделать модульную большую часть этой сложности и, надеюсь, устранит многие зависимости, которые у вас есть между логикой приложения и представлениями.

Я большой сторонник структуры RobotLegs, которая реализует шаблон mvcs и предлагает инъекцию зависимостей для использования во всем вашем проекте. Есть и другие, такие как pureMvc, Cairngorm, Mate. Посмотрите вокруг и посмотрите, что лучше всего подходит вашему проекту.

Мне кажется, что вам действительно нужно сделать большой рефакторинг, который является рискованным процессом в таком большом проекте. Это может стоить того, если вы пытаетесь сохранить его. Если вы собираетесь реорганизовать рефакторинг в рамки. Вероятно, это область, которая даст вам больше всего шансов для вашего доллара (фунт за бриты;))

Answer 2

Стартер беседы Джеймса Хэя - хороший, но для ОГРОМНЫХ приложений мне потребуется время, чтобы проверить и рассмотреть управление памятью для некоторых предложений в этом ответе/разговоре. RobotLegs замечательный и все, но я буду беспокоиться о «чрезмерной синтаксизации» и возможных проблемах управления памятью, которые он создаст (хотя я должен признать, что я никогда не использовал и не избегал robotLegs из-за использования синглтонов). Если вы думали о IoC и инъекции зависимостей (например, о том, что предоставляет robotLegs), я бы предложил взглянуть на swiz - мне очень понравилось, что новая тренировка «пример-направление» взята. Моя единственная проблема с ним (в текущей бета-версии) заключается в том, что у них есть некоторые проблемы с очисткой, хотя эти проблемы достаточно легки для исправления (просмотрите их источник и в любое время, когда вы полностью удалите компонент со сцены, вам придется сыграть в профилирование игра и убедитесь, что все очищается - нам пришлось создавать временные функции, чтобы удалить диспетчеров изменений и уничтожить «экземпляры списка отображения списка», пока они не зафиксируют этот материал).

В проекте, который я возглавлял, было много потенциальных проблем, о которых вы должны беспокоиться.В нашем приложении ERP есть тысячи модулей, и все работает на клиентских компьютерах по часам/дням, постоянно загружая и выгружая модули. Сбор мусора и управление памятью были и есть проблемы.

Что касается использования помощника, раздражающего carhorn или pureMVC, мы создали свою собственную инфраструктуру два года назад. Он заимствовал идеи от cairngorm, но в целом мое предложение - использовать все, что вы можете быстро изучить, понять и научить, думая о сборке мусора. В наших внутренних классах Model и View теперь используется swiz (для недавно разработанных модулей), и это упростило удобство и удобочитаемость кода.

Надеюсь, что мой blabbing помог хотя бы немного. Удачи.

Answer 3

Похоже, вам просто нужно чистое разделение компонентов интерфейса и домена. Посмотрите на component guidelines и Presentation Patterns, обсужденный Мартином Фаулером, особенно Presentation Model.

Чтобы собрать эти штуки, вы можете использовать контейнер IoC, например, Spring ActionScript. Это неинтрузивная структура, которая позволяет вам разделять слои.

Не позволяйте рамке встать на вашем пути. Я видел массовое неправильное использование фреймворков, таких как PureMVC и Cairngorm, главным образом потому, что применяю их по принципу «все или ничего».