Статические функции или события в 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)); 

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

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

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

Answer 1

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

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

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

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

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

Удачи.