Рекомендации для больших приложений Flex?

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Надеюсь, моя болтовня хоть немного помогла. Желаем удачи.

Answer 3

Кажется, что вам просто нужно четкое разделение компонентов пользовательского интерфейса и домена. Изучите рекомендации для компонентов и Шаблоны презентаций , рассмотренные Мартином Фаулером, особенно Модель презентаций .

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

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