Статические функции или события во Flex?

Question

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

Сначала я объясню основную архитектуру, а затем задам свои вопросы.

В этом приложении есть статическая утилита, которая отправляет / получает HTTP-запросы. Когда компонент желает запросить данные через HTTP, он вызывает статическую функцию в этом классе:

Utility.fetchUrl(url, parameters, successHandler, errorHandler);

Эта функция вызывает другую статическую функцию в компоненте отслеживания, который отслеживает, сколько времени занимает запрос, сколько отправлено и т. Д. Вызов выглядит очень похоже в служебном классе:

public static function fetchUrl( ... ):void {
    Tracker.startTracking(url, new Date());
    ...
    Tracker.stopTracking(url, new Date());
}

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

В конечном счете, я бы хотел, чтобы каждый компонент создавал пользовательское событие, которое отправляется в высокоуровневую инфраструктуру. Оттуда сама структура будет передавать событие в правильное место. Другими словами, те компоненты, которые должны выполнить HTTP-запрос, будут отправлять событие, подобное этому:

dispatchEvent(new WebRequestEvent(url, parameters, successHandler, errorHandler));

Оттуда Parsley (или другая структура) будет следить за тем, чтобы событие отправлялось в правильное место, которое могло бы обрабатывать функциональные возможности и выполнять все, что необходимо. Это также позволило бы мне перейти к более разделенной архитектуре MVC, в которой результаты веб-запросов обрабатываются моделями, внедряемыми платформой в их собственные соответствующие представления.

Я бы хотел сделать то же самое с функцией отслеживания.

Есть ли недостатки в использовании механизма, основанного на событиях, в сочетании с такой структурой, как Parsley? Лучше придерживаться статических функций / переменных и использовать доступ в стиле синглтона? Если так, то почему? Будет ли это в конечном итоге вызывать больше проблем в будущем, чем оно того стоит?

Answer 1

Итак, короткий ответ о недостатках событий:

1. Немного больше веса в системе для использования событий.Слушатели, пузыри, захват и т. Д. Должны управляться системой.Гораздо меньше проблем, когда вы находитесь за пределами иерархии отображения, но все же дороже, чем прямые функции.(опять же, избегайте предварительной оптимизации, так что сделайте это правильно, а затем быстро).

2. «Мягкие» циклические зависимости могут возникать в сложных асинхронных системах.Это означает, что в итоге вы получите случай, когда A вызывает событие.B отмечает, что A изменилось, поэтому обновляет C. C вызывает событие.D замечает, что C изменился и обновляет A. Обычно он не загружает ЦП, но все еще является бесконечным циклом.

3. Иногда требуется принудительная буферизация / блокировка функций.Скажем, компоненты A и B оба вызывают одно и то же событие.Возможно, вы не захотите, чтобы C запускался дважды (например, при получении новых данных с сервера), поэтому вы должны убедиться, что C помечен как «занят» или что-то в этом роде.

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

Удачи.