Первое, что можно отметить, так это то, что предложенный в Parsley механизм обмена сообщениями/событиями позволяет легко и просто разделить уровень представления от уровня бизнес логики, который можно так же легко отделить от уровня обращения к данным, если нам это понадобится.

Мне кажется вполне оправданным разделить сообщения идущие из уровня отображения к уровню бизнес логики от сообщений идущих в обратном направлении. Очень удобным выглядит подход, когда из уровня отображения посылаются события, а обратно сообщения. Такой вариант передачи данных легко отслеживать (если такое вообще применимо к асинхронным вызовам), он требует меньше кода и убирает излишнюю иерархию классов (не надо расширять EventDispatcher на уровне бизнес логики). В остальном эти подходы похожи. Так же для отображения отдельных компонентов в формах и прочее удобно использовать связывание объекта (MessagheBinding). Что избавляет нас от необходимости обработки сообщения и извлечения информации. Две строчки - мелочь, а приятно.

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

На данном рисунке красным цветом отображены события, а синим сообщения. Стрелки зелёного цвета я позволил себе использовать для указания прямого вызова. Данная картинка немного отличается от модели моего примера в двух местах. Во первых обычно даже для генерации события бывает мало информации, которую может нам предоставить компонент, который генерирует событие, по этому в компоненты можно внедрить объекты, которые будут предварительно собирать информацию, чтобы отравить максимально полный запрос в уровень бизнес-логики. Второй момент - уровень доступа к данным не посылает данные на прямую в уровень отображения, обычно полученные данные надо обработать и/или сделать дополнительные запросы и только после этого уже отсылать сообщение на уровень отображения, включив в сообщение полученные результаты в виде объектов из предметной области - модели.

Если мы рассматриваем ситуацию, когда данные формируются на сервере, то в данном случае правильно рассчитывать, что данные придут нам одним пакетом, и нам не надо будет дополнительно их обрабатывать, в таком случае вполне оправданным будет генерация сообщения с данными прямо на уровне DAO/SERVICE.

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

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

Удачной разработки!

Комментарии

Добавить новый Поиск

!joomlacomment 4.0 Copyright (C) 2009 Compojoom.com . All rights reserved."