Почему посредники связаны с прокси в Flex PureMVC?

Я только недавно изучил структуру PureMVC и немного запутался в связи между объектами Proxy и Mediator. Ссылки на этой странице связаны с некоторыми документами, описывающими структуру. (Обратите внимание, ссылки на вышеупомянутой странице открывают PDF-файлы.)

Диаграммы и примеры PureMVC, которые я исследовал, часто показывают прямую связь между посредником и прокси. Когда состояние прокси обновляется, вместо отправки нового уведомления, посредник (который извлекает ссылку на прокси из фасада) обновляет свое состояние.

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

Разве не было бы разумнее, чтобы прокси-объекты отправляли свои собственные уведомления при обновлении их состояния, которые перенаправляются заинтересованному посреднику с помощью фасада?


apache-flex puremvc coupling
person Community    schedule 14.08.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Даже если вы обновите посредник с помощью уведомлений, он будет связан с прокси, но это нормально, так и должно быть.

Пока вы не подключаете прокси, я бы сказал, что все в порядке.

Хуан

person Community    schedule 14.08.2009
comment
Простите, я не понимаю. Если посредник получает уведомление от фасада (которое было отправлено прокси) и содержит объект данных, который используется для обновления представления, как он связан с прокси? Вы имеете в виду, что они косвенно связаны через Уведомление? - person bedwyr; 15.08.2009
comment
Извините, предыдущий комментарий не очень ясен. Я имею в виду, что посредники всегда связаны с прокси хотя бы потому, что они должны представлять то, что внутри них. Взгляды вообще нужно знать о моделях. Для меня нет большой разницы между обновлением представления / посредника через уведомления или его обновлением через прямой доступ к прокси (с использованием фасада). Если не наоборот (прокси-сервер должен знать о посреднике), я думаю, что все в порядке. Надеюсь, в этом есть немного больше смысла! Хуан - person Juan Delgado; 15.08.2009
comment
На самом деле, в этом больше смысла - спасибо. Я читал несколько сообщений на форумах PureMVC, и по этому вопросу, похоже, существует ряд различных мнений, многие из которых довольно яростно придерживаются. Спасибо за ваши мысли! - person bedwyr; 16.08.2009

arrow_upward
2
arrow_downward

Разве не было бы разумнее, чтобы прокси-объекты отправляли свои собственные уведомления при обновлении их состояния, которые перенаправляются заинтересованному посреднику с помощью фасада?

Да, именно это и должно произойти. PureMVC - это просто реализация шаблона Notifier / Observer с облегченной структурой MVC, связанной фасадом. Я настоятельно не рекомендую связывать прокси с посредниками; разрешать посредникам отвечать только на уведомления, отправляемые прокси-сервером при изменении состояния данных. Это позволяет полностью разделить эти классы.

Если вы используете Flex, я бы порекомендовал HydraMVC / HydraFramework, который является специфичным для Flex портом PureMVC MultiCore, имитирующим API PureMVC, но гораздо менее подробным и включает способ разделения взаимодействия с сервером. из прокси через DelegateRegistry. (Полное раскрытие информации, я являюсь основным разработчиком этого проекта, однако он полностью OSS и бесплатен для использования / участия.) Независимо от того, какую структуру MVC вы реализуете, я все же настоятельно рекомендую полностью разделить прокси / посредники с помощью уведомлений.

person Community    schedule 17.08.2009