Унаследованные классы и динамические представления в PureMVC (AS3)

Question

Мне было интересно узнать о лучших методах представления унаследованных классов в PureMVC в этой ситуации:

• Несколько классов наследуют BaseClass (скажем, InheritedClass1 и InheritedClass2)
• Каждый InheritedClass имеет соответствующее представление (производное от базового класса представления, но каждое уникальное)
• С данным набором данных (скажем, ArrayCollection объектов InheritedClass1 / 2) соответствующие представления должны быть загружены динамически.
• Набор данных является относительно большим, поэтому TileList был бы хорош (поскольку он только создает экземпляры объектов, которые отображаются в данный момент)

Я могу придумать пару решений, но я считаю, что они слишком «взломаны», чтобы быть лучшим решением:

• В представлении: ретранслятор поверх BaseClassView, который приписывает представление к состоянию (установите состояние «InheritedClass1» для добавления объекта InheritedClass1) Плюсы: нет ненужного увеличения памяти (объекты состояний создаются при необходимости) Минусы: просмотр зависит от типов данных, поэтому добавляет связь

• В посреднике: зацикливание на ArrayCollection и addChild () представления на основе типа данных Плюсы: работает. Минусы: Посредник добавляет вещи в Представление, что побеждает точку разделения Посредника и Представления. Медленнее, чем повторитель.

Любые комментарии или другие предложения будут оценены. Спасибо!

Answer 1

Минусы: вид зависит от данных типы, поэтому добавляет сцепление

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

Таким образом, подача коллекции VO в ваш компонент представления не добавляет «плохую» связь «Плохая» связь - это когда компонент представления знает о том, как добраться до уровня Модели и манипулировать Прокси, который содержит данные. Или когда Прокси на уровне модели знают, как получить в свои руки компоненты представления или их посредников, чтобы вставлять в них данные.

Посредник добавляет вещи в представление, который побеждает точку разделение Посредника и Видения.

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

Для связи с компонентом представления другие субъекты отправляют уведомления, на которые Посредник слышит и реагирует на них, манипулируя открытым интерфейсом API компонента представления; накормить данные или вызвать методы. Это эффективно удерживает остальную часть приложения от необходимости знать что-либо о компоненте.

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

Таким образом, компоненты Mediators и View вместе образуют уровень просмотра приложения.

- = Cliff>

Answer 2

Посредники являются частью представления. Как бы вы отделили их от Видения, вне меня.

Я получил вариант 2.

Вот тема на форуме pureMVC: Динамическое добавление Просмотр компонентов: где мне это делать? . Пост «pureMVC» должен вас заинтересовать.

Кроме того, размер набора данных может быть проблематичным. Если он действительно большой, вам следует рассмотреть возможность использования List с визуализаторами вместо добавления компонента для каждого элемента (так делают ретрансляторы). Что еще больше усложнит ситуацию, потому что вам придется обернуть свои данные, чтобы не связывать основной компонент модели.

Answer 3

Ответ прост, если вам нравится первый пример. Почему бы не иметь карту (Object ()) на посреднике, которая назначает тип данных для просмотра компонента (или состояний). e.g.:

private static var map:Object = {"ic_oneType": "ic_oneState",
                                 "ic_twoType": "ic_twoState"}

И посредник может назначить эту карту для BaseClassView.

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

Answer 4

Минусы: Посредник добавляет вещи в Вид, что побеждает точку разделения Посредника и Вид

Не совсем: это то, что в документации называется парой сотрудничества, и их следует рассматривать как таковые.