Нужна помощь в вопросе «быть или не быть» по поводу Flex'а

Silverlight и Flex. есть ещё варианты?

if
... Silverlight. Впрочем, его тут же отмели по целой куче причин.
then
ничего кроме флекса на горизонте не видно(мне не видно).

Так в чём вопрос?

По сути дела, мой вопрос был в том, может ли Флекс те или иные вещи или не может. А точнее еще - как может. Чтобы не получилось обмена шила на мыло. Очень интересуют как причины "за", так и "против" использования Flex как замену HTML+JS.

Вопрос в том не сменят ли они шило(аякс) на мыло(флекс).

Имхо нет, флекс менее геморней чем аякс.

Так же я не соглашусь с Ростом, насчет того чтобы делать сайт сразу на 4ерке. Ориентироватся да стоит, но нужно понимать, что это софт, а софт имеет тенденцию гробить дедлайны, очень глупо будет смотреть на конкурентов, которые выпускают свои Флекс3 приложения-конкуренты, пока авторам придется ждать релиза =)

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

to Vasilio Ruzanni
flex может одно - заметно повысить скорость разработки приложения, а вот AS может всё. Если он чего не может - это просто мы не знаем КАК он это может))).
to Nirth
я думаю: если срок ~год то ждать не прийдется.

По поводу Тольятти, обратите внимание на эти новости:

Жители Самары — айда дышать воздухом AIR и пробовать силу Flex

RIA в Самаре: Adobe Flex и Adobe AIR — приходите подышать!

An, ну будем надеяться, что AS и правда может все =) А разобраться как - эт всегда дело техники.

По проекту - промежуточные релизы (Preview, Alpha, Beta и так далее, с неполным функционалом) обязаны быть раньше, не позже пары месяцев с начала проекта, однако в стадию RTM продукт пойдет не раньше, чем через год.

По поводу "последних версий" - тут и хотелось бы узнать у профи - насколько Flex 4 может дать прирост в скорости или удобстве разработки и какие при этом существуют реальные риски изменений чего-либо в составе Flex 4 к релизу (в частности - существенных изменений - так, что если вдруг придется рефакторить всю систему с головы до ног)?

to Vasilio Ruzanni
Говорить о приросте производительность до выхода релиза рановато...)
Риски изменений зависят от конкретного проекта. Если Вам с головой хватает функционала из SDK от 3 версии - рефакторить вообще ничего не прийдеться. Но если охота пощупать 3D и другие фичи то нужно сразу садиться за 4 со всеми последствиями.

Новая версия даёт новые возможности. Так везде. Если Вам эти возможности нужны... если нет ....

Правда есть одно но:
Я знаю одного хорошего флешера который пишет на AS2 тк ему этого с головой хватает. Это уже крайности. Особенно приятно потом такой проект расширять (учитывая что мы в одной команде)))

to Vasilio Ruzanni
На Флексе разработка в разы быстрее, но минусы довольно существенны:
- большой тормозняк при каких-то манипуляциях, проц. может и за 100% зашкалить на время. А это раздражжает, даже если врема подвисания 1-2 сек.
- вывод больших данных невозможен без разбиения на маленькие страницы, а если еще и вид представления довольно сложен, то вообще труба (6-8 записей максимум, против ХТМЛ 500 - 1000 записей).

Эти выводы -- на основе разработки комплексного интранет приложения на Флекс 3

ir73, дельная мысль. Вот это больше всего и волнует.

6-8 записей?? Или это в пример - как отношение производительности, то есть 8 против 1000?

Кстати, на клиенте, если это и HTML+JS всяко рассматривается использование фреймворка типа ExtJS. Неужто, Флексовые компоненты менее производительны?

Насчет тормозов у нас, при изучении темы Флекса, возникло только одно нарекание - нет многопоточности (в отличие от того же Silverlight) - соответственно, нельзя разделить на потоки обработку графики и расчеты+обращения к сервисам.

Раз уж зашел разговор о производительности - всплывает вопрос: Влияет ли как-то на производительность использование Adobe AIR вместо "голого" Flash Player'а в браузере?

6-8 записей?? Или это в пример - как отношение производительности, то есть 8 против 1000?

Раз уж зашел разговор о производительности - всплывает вопрос: Влияет ли как-то на производительность использование Adobe AIR вместо "голого" Flash Player'а в браузере?

to Vasilio Ruzanni

Кстати, ответа на свои вопросы вы тут не найдете: сколько людей, столько и мнений. А мнения будут диаметрально противоположными, каждый рассуждает основываясь на своем проекте.
Так что максимум что вы сможете сделать, это все прочитать, а решать вам надо будет самостоятельно.

ir73, Ну разумеется, я отдаю себе отчет в этом. Решение за меня всяко никто не примет.
Однако, радует, что люди, хоть и советуют с высоты своей колокольни своего опыта, все советы по делу и по теме, есть о чем подумать. Посему, хотелось бы услышать еще мнений профи.

>- вывод больших данных невозможен без разбиения на маленькие страницы, а если еще и вид представления довольно сложен, то вообще труба (6-8 записей максимум, против ХТМЛ 500 - 1000 записей).

Уверен? может что-то не так делаешь? Может неверное "представляешь" данные?

Вывод данных используя стандартные средства (читай не сильно извращаясь в оптимизации) позволяет вывести практически любое количество данных (ограничено как я понимаю только памятью гига для флеш плеера, в моем тесте он умер на 1.7Гб + 1.7Гб VM).

Я ради интереса проэксперементировал List, обычный рендерер, 9й флешплеер и фф справились с отображением 5 500 000(!) элементов типа

{label: (i)+'. sdfljhsfk kjsdfhsdkjfh ksjdfhsjkdhsdkjf hsdf hsdfkjsdhf jksdhfkj shdfkjsdhf ksjdfh skdjdfh ksjdfh skdhf sdkjfhsd fkjsdhf ksdjfh sdfkhsdf jksdhf '+Math.random()};

тормозов видно небыло в процессе скролла ) вернее листу пофиг сколько отображать -- просто массив не поместился в памяти).

Можешь указать случам где нужно манипулировать с таким количеством данных? Онлайн?.

>Раз уж зашел разговор о производительности - всплывает вопрос: Влияет ли как-то на производительность использование Adobe AIR вместо "голого" Flash Player'а в браузере?

в АИР работает быстрее) точно сказать не могу не эксперементировал, но случайно наткнулся на то что если загрузить веб страницу с флеш приложением в АИР (используя его HTML) то работает в 1.2-1.4 раза быстрее :)

По поводу Flex 3 vs Flex 4 - зависит от коллектива разработчиков. 4я версия флекса полностью переработана, и это даст преимущество на старте в случае, если разработчики не знакомы с флекс вообще. Если команда опытная, она сможет начать разработку на третьей версии, ориентируясь на архитектуру 4й, хотя все равно при переходе на 4й флекс переписывать придётся много.

Флекс 3 не сравним с html+ajax в плане удобства работы с текстом, это узкое место 9го плеера, во флекс 4 и 10м плеере работа с текстом поставлена на новый уровень (http://opensource.adobe.com/wiki/display/flexsdk/Gumbo+Text+Primitives).

FSB, а насколько 4-й Flex реально сейчас приспособлен для разработки на нем? То есть, понятно, конечно, что что-то будет переделываться, но в целом, как дела у него обстоят с "feature-complete"-ностью? И есть ли возможность "в узких местах" использовать фичи Flex 3?
А то как бы не получилось как с Silverlight 2.0 - много чего нет (всяких нужных компонентов), самим делать смысла нет, так как MS в итоге все равно все сделает, но и замены нет никакой на текущий момент.

Vasilio Ruzanni проектов на 4м пока не видел и сам не имел, знаком только по вылоденным докам и статьям, но Артемий Малков на своём докладе о Gumbo утверждал, что третьи компоненты в Gumbo работают на ура, я не проверял :)

>Насчет тормозов у нас, при изучении темы Флекса, возникло только одно нарекание - нет многопоточности (в отличие от того же Silverlight) - соответственно, нельзя разделить на потоки обработку графики и расчеты+обращения к сервисам.

При большом желании можно реализовать слабое подобие многопоточности с помощью Timer-а. Иногда очень помогает, мы на проекте делали расчеты таким образом, без таймера анимация зависала на время расчета, при использовании таймера в 1 mc зависание отсутствует (это работает если расчеты могут быть рекурсивными или их можно разбить на этапы)

Кстати, ответа на свои вопросы вы тут не найдете: сколько людей, столько и мнений.

- большой тормозняк при каких-то манипуляциях, проц. может и за 100% зашкалить на время. А это раздражжает, даже если врема подвисания 1-2 сек.
- вывод больших данных невозможен без разбиения на маленькие страницы, а если еще и вид представления довольно сложен, то вообще труба (6-8 записей максимум, против ХТМЛ 500 - 1000 записей).
Эти выводы -- на основе разработки комплексного интранет приложения на Флекс 3

Повторюсь, это в моем случае, то есть в случае со сложной презентацией одной записи (одна запись: картинка, 2 таблички, текст, все это еще и разворачивалось и сворачивалось с анимацией). В случае обычного листа может быть и 100 записей, и более, но в целом да, по производительности тут засада.

На мой взгляд, здесь как раз тот случай, когда флекс неправильно готовят. Именно об этом я говорил здесь:

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

Чего стоит одно только неправильное использование DataBinding - можно любую аппликуху тормозной сделать. Вот, целая статья об этом вышла: ловушки в которые попадают пользователи DataBinding.

А правильная готовка Flex дает такие проекты, как графические онлайн-редакторы от Aviary мультиплатформенные ОС Glide OS (еще ссылка).

А вот весьма тяжеловесный Excel онлайн (spreadsheet на Flex) - idubee.

Как видите, там везде много данных, особенно в последнем примере - и ничего, рабоатет все :)

Всех приветствую, внесу доп. ясность про фреймворки. Про то, какой фреймворк (3 или 4) выбрать с точки зрения проекта я бы сформулировал к вам вопрос так: "С чем ваше приложение будет работать больше - с интерфейсом или с данными?" Основная идея в выпуске версии 3->4 - это Design in Mind, т.е. значительная переработка всего того, что отображается, чтобы оно было легче / быстрее / гибче.
Если вам нужно делать кучу нестандартных компонентов + поддерживать / развивать их на протяжении нескольких лет, то вы серьезно сэкономите, если будете иметь в виду Flex 4. Если же у вас интерфейсы достаточно простые, состоящие из стандартных компонентов, то не заморачивайтесь и делайте на Flex 3. Потом портировать при желании будет несложно - заменой теймспейса (+ пока не видел, но я думаю будут тулзы для портирования).

По поводу производительности на больших списках из простых элементов - никаких тормозов при грамотной реализации не замечал. На эту тему недавно как раз сделал тесты: http://riapriority.com/blogs/slon-vsapogah.php/2008/09/03/advanced_datagrid_itemrenderers_speed_ef

Это достигается за счет того, что рендерится реально всегда совсем немного элементов (видимые + несколько в кеше).

Другое дело, что при наличии на экране большого количества объектов наступают тормоза, и наступают они раньше, чем в HTML.

По поводу 3/4 - даже не знаю, что лучше. Мне кажется, основная проблема в том, что пользователям для просмотра (на этапе Alpha/Beta/... и в случае задержки релиза) придется скачивать себе бету плеера. А это сложнее, чем если плеер сам обновится.

Если нужно идти в production в течение ближайшего года, Flex это единственное реальное решение имеющееся сегодня. Flex 4 выйдет только через год и будет сильно меняться - не стоит рисковать.
.Net девелоперы используют Flex и ВебОрб для увеличения скорости обмена даннымы с сервером.

Посмотрите PDF моей презентации "Facelift your SOA with RIA" на сайте www.faratasystems.com под меню Conferences.

Еще такой вопрос, уже более предметный (ну, сами понимаете, нужно взвесить все аспекты:)).

При использовании Flex 3 для разработки UI-уровня системы (комплекса систем), уже сейчас понятно, нужно использовать разного рода паттерны и микроархитектуры.

После достаточно серьезного изучения вопроса, выбор, по сути встал между двумя разработками: Cairngorm и Mate.
Первый - как бы это лучше выразиться, более прямолинейный и достаточно понятный, с учетом того, что команда разработки хорошо знакома со всеми этими принципами и паттернами. Второй - содержит отличные идеи по декларативному объявлению карт событий, что тоже безумно удобно, так как "менее многословно" (однако еще неизвестно, могут ли быть какие-то подводные камни в нем).

В связи с тем, что предполагается использовать технологию как основополагающую для большинства user-интерфейсов, хотелось бы узнать - что из этого оптимальнее использовать в крупном проекте? То есть, какой код проще поддерживать и какие неявные преимущества есть у обоих фреймворков? А возможно ли использование и того и другого сразу?

Да, еще вопрос касающийся модульности - нормально ли эти микроархитектуры укладываются в концепцию модулей Flex-приложений?

2 Vasilio Ruzanni
Я бы не советовал налегать на паттерны очень сильно (всему своя доза), иначе год получается как швейцарский ножик, может делать все но результата "отлично" добится будет трудно.

> концепцию модулей Flex-приложений?
Cairngorm точно пашет, Mate вышел после того как я сменил образ жизни.

> то из этого оптимальнее использовать в крупном проекте?
Если вам кто то ответит на поставленый вами вопрос, не слушайте его, нельзя посоветоваь фреймворк имея на руках вместо спецификаций , слова типа "крупный" и "проект",

Если вам кто то ответит на поставленый вами вопрос, не слушайте его, нельзя посоветоваь фреймворк имея на руках вместо спецификаций , слова типа "крупный" и "проект",

Однако можно посоветовать то, чего делать не стоит.

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

Я несколько месяцев назад пришел в крупный проект на Flex, который писался до меня несколько лет. Изначально использовался Cairngorm, однако потом он был заброшен, и его останки видны то там, то тут.

Сам я написал 5-10 небольших проектов (до 150 часов) с использованием Cairngorm, и поэтому считаю свое мнение довольно устоявшимся и взвешеным.

1. Cairngorm хорош только в случае:

   - начинающий разработчик, умеющий с толком применять фреймворк, а не прямо следовать простейшим Samples

   - проект до 100 часов работы

   - отсутствие модульности

2. Cairngorm очень плох, крайне вреден, противопоказан в случае:

   - проект рассчитан на более чем 200 часов

   - наличие модульности

3. Минусы Cairngorm:

   - Огромное количество синглтонов (помеха при модульности)

     - Единый контроллер, который превращается в неуправляемый гигантский класс (анти-паттерн God object)

   - Команды, не знающие своего контекста, если им не передавать его через событие

   - Если передавать данные командам в строгой типизации и вообще делать все по правилам, то на элементарное действие уходит очень много кода и классов:

     - Для каждой небольшой группы действий - класс события, в нем - константа для каждого действия

     - Для каждого действия запись в едином контроллере

     - Для каждого действия класс команды

     - Итого - обработка нажатия кнопки это минимум создание 1 класса и обновление 2-х других

   - Структура пакетов Cairngorm препятствует модульности приложения, предлагая событиям/командам/vo расти из events/commands/vo

   - Из View просто нельзя добраться до кода контроллера по F3, надо ползти по пакетам :)

   - Модель-синглтон может превратиться в неуправляемый God-класс при росте приложения

   - Из-за модели-синглтона усложняется реинициализация приложения - logout/login

Короче говоря, для большого проекта предлагаю вам не использовать Cairngorm.

К Mate отношусь с большим уважением благодаря недавнему докладу Constantiner'a, однако уверен что достаточно скоро вы найдете и в нем серьезные проблемы.

Вообще, подобные фреймворки - не для крупных проектов. Если вы серьезно и надолго взялись за проект - займитесь проектированием, возьмите из фреймворков лучшие идеи. И не усложняйте слишком :) Как учит нас Б. Мейер, модульность - один из главных принципов ООП. Есть и другие всякие :) Если подумать и постараться, то все получится :)

Блин :) А так старался, теги всякие писал, все поехало...

Slon_vsapogah, спасибо за подробное рассмотрение, но! Ряд моментов натолкнул на встречные вопросы и суждения:

1. - Итого - обработка нажатия кнопки это минимум создание 1 класса и обновление 2-х других;
А как вы себе это представляете по другому? Просто обработчик кнопки "прямо на месте"? Будет code-mess.

2. - Структура пакетов Cairngorm препятствует модульности приложения, предлагая событиям/командам/vo расти из events/commands/vo;
А нельзя сделать так, чтобы каждый модуль содержал "events/commands/vo"? Плюс имел возможность обрабатывать "глобальные" Event'ы?

3. - Для каждой небольшой группы действий - класс события, в нем - константа для каждого действия
Не вижу явно отрицательных сторон. Впрочем, ровно как и явно положительных моментов.

4. - Для каждого действия класс команды;
Что подразумевается под действием? А вообще, сдается мне, что это правильный подход предлагается.

5. - Команды, не знающие своего контекста, если им не передавать его через событие;
Команды, не знающие контекста - очень гуд! Значит их можно использовать с разными контекстами не переписывая.

6. - Единый контроллер, который превращается в неуправляемый гигантский класс (анти-паттерн God object);
Не вижу явных минусов, впрочем, пока не знаю, как выглядит большой проект на Флексе. На серверной стороне мы используем MVC и разумеется имеется множество контроллеров, для каждого типа объекта, а каждый метод отдельного контроллера - одно действие.

Соглашусь про синглтоны - сами их не очень любим, так как при написании unit-тестов их сложно сымитировать (сделать mock-объект).

Кстати, как у фреймворков с предрасположенностью к unit-тестам? У нас это обязательная практика.

P. S. А про Mate, кстати, хотелось бы тогда услышать от самого Constantiner'а, ну или кого-то еще, кто хорошо знает этот фреймворк.

P. S. S. Проект большой не просто так, а за счет огромного количества самих бизнес-сущностей. Однако, по всей системе, способы работы с этими сущностями в 90% случаев будут повторяться. Именно поэтому, мы уже сейчас считаем оправданным использование архитектурного Framework, чтобы все эти ситуации обрабатывались не так, как каждому разработчику захотелось, а в некоей стандартизированной манере - чтобы все понимали, как это делают другие.

P. S. S. S. А изобретать свой фреймворк при том, что уже есть хорошие наработки у других - гиблое дело. Можно утонуть в решении системно-архитектурных задач, вместо решения прикладных. Это пройденный этап и есть отменный опыт в подобного рода ошибках :)

Yakov Fain - я добавил в ваш пост ссылок, спасибо за комментарий!

Slon_vsapogah — я поправил разметку в вашем посте.

Сразу хочу сказать, что я обожаю повторное использование, фреймворки и вообще не считаю себя вполне взрослым программистом. Уж тем более не призываю вас изобретать велосипед. Наоборот, призываю использовать MVC - то, вокруг чего растут все фреймворки.

1. - Итого - обработка нажатия кнопки это минимум создание 1 класса и обновление 2-х других;

А как вы себе это представляете по другому? Просто обработчик кнопки "прямо на месте"? Будет code-mess.

Можно во view создать команду, запустить ее путем вызова ее метода, подписаться на ее события и жить спокойно. Как говорится, простота - залог здоровья:

public function button_clickHandler(event:MouseEvent):void 

{

    var command:LoadContectCommand = new LoadContentCommand();

    command.addEventListener(Event.COMPLETE, completeHandler);

    command.addEventListener(ErrorEvent.ERROR, errorHandler);

    command.execute(userNameInput.text, passwordInput.text);

}

Мы имеем 1 новый класс на обработку клика, инкапсулирующий логику.

Минусы данного решения:
- Затруднено повторное использование - но только по сравнению с Mate. По сравнению с Cairngorm повторно использовать этот view было бы так же непросто.
- view в общем случае связан с несколько бОльшим количеством сущностей из не-view, чем в Cairngorm и тем более Mate

Плюсы по сравнению с Cairngorm:
В Cairngorm для создания подобного кода необходимо дополнительно создать:
- Класс события LoadContentEvent, в нем - свойства userName и password
- Добавить вызов addCommand(LoadContentEvent.LOAD, LoadContentCommand) в контроллер
- Не нужны view-helper-ы (каждый из которых - синглтон), можно диспатчить события из логики
- Заметьте, насколько непрямой становится связь действия с логикой. Если вы хотите просто посмотреть, что происходит по клику, нужно выполнить порядка 5 действий. В вышеуказанном случае достаточно одного (Ctrl + клик по методу execute). Код как бы разбегается в разные стороны.
- А еще в вышеуказанном решении нету ни одного из указанных мной ранее минусов Cairngorm.

Плюсы по сравнению с Mate:
- Простой дебаг (пробовали когда-нибудь дебажить декларативный код?)
- Быстродействие
- мЕньший вес
- бОльшая гибкость
- Возможность быстрого доступа к коду логики

Что еще сказать... Если взять Cairngorm, Mate или Abcdef, то это гарантия того, что ваши программисты напишут чудесный код? Абсолютно НЕТ, и со мной, думаю, все согласны.

Выводы
Если вы дадите своей команде Mate или Caigngorm и скажете - "Погнали!" - и ребята начнут писать каждый в своей тарелке по модулю системы, то через 2 месяца получится top4top.

Хорошо поставленный процесс проектирования (возьмите лучшее из фреймворков!) а затем и разработки - вот что скорее всего даст отличный результат. К сожалению, как это делается в команде - не знаю.

P.S: Вообще, по поводу Mate надо смотреть. Его применение не обязывает всему работать по-матевскому. Правда, ходят слухи, что один синглтон там внутри все-таки есть... 8-/

Slon_vsapogah, с доводами вполне согласен, ну это речь о том, что все надо использовать с умом и без фанатизма. У нас, слава богу, пока с этим все в порядке :)
С точки зрения использования какого-то из фреймворков, действительно, не хотелось бы всяких "лишних наворотов" и при этом хотелось бы иметь нормальную возможность поддерживать много кода.

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

По поводу дебаггинга декларативного кода во Флексе пока не в курсе - как раз и выбираем. А какие здесь трудности? Кстати, unit-тестировать объекты Mate возможно?

По поводу Mate лучше спросить у Constantiner-a, в отчете о последней встрече есть его презентация про Mate.

А скажите, вот вы всякие фреймворки приводите, а для чего они все? Флекс же уже фреймворк, нафига еще надстройку городить?

А скажите, вот вы всякие фреймворки приводите, а для чего они все? Флекс же уже фреймворк, нафига еще надстройку городить?

Флекс - компонентный фреймворк. Mate, Cairngorm, PureMVC и т.п. - микроархитектурные/архитектурные фреймворки. Можно сказать, что они говорят, как управлять компонентами Флекса (или другого компонентного фреймворка).

Вот яркий пример того, что грамотно заданный вопрос - половина ответа.

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

Это не хорошо и не плохо, просто надо учитывать данный факт при планировании проекта и тщательнее выискивать в нем подобные "засады".

20% функциональности пишутся за 80% времени

ir73, за 80% времени, отведенного на реализацию проекта. Это принцип Парето. См http://ru.wikipedia.org/wiki/Закон_парето

flaMaster, ага, и практика показывает, что этот принцип 80/20 работает все время! за 20% времени действительно реализуется основной функционал, затем все остальное время формируется сложный функционал и нюансы, нюансы, нюансы!

Vasilio Ruzanni,
вы не про такую возможность спрашивали? ;)

FlexUnit is a unit testing framework for Flex and ActionScript 3.0 applications and libraries. It mimics the functionality of JUnit, a Java unit testing framework, and comes with a graphical test runner.

unodj, ну разумеется мы уже нашли FlexUnit и даже продвинутый TestRunner для него.
Я спрашивал в контексте фреймворка Mate - возможно ли тестировать связи, которые объявляются декларативно с его помощью.

Кстати, спасибо всем за ответы. Экскурс в Mate и Cairngorm расставил множество точек над "и", теперь осталось все полностью попробовать на практике. Сейчас, как уже и упоминал в вопросе выше, очень интересует аспект unit-тестирования того, что получается с помощью Mate.

На мой взгляд автор вопроса недостаточно полно изложил задачу.
Кто пользователи.
Интернет или интрАнет.
Учитывая опыт (кстати какой, сколько, какая версия .Net) в С#, я бы не посоветовал прыгать с воду FLEX.
Сам нахожусь постоянно в той же ситуации. Внутренние сайтиы все на ASP.NET, максимум добавки на FLASH(включая AS3).
Несколько раз пытался прототип сделать на FLEX (3.0).
Если често было жутко неудобно все. Начиная от среды - перепробовал все законное и незаконное, кончая построением системы как таковой. Учитывая уровень знания AC3, средний -, достаточно тяжело было мириться с тормознутостью загрузки (после FLASH), достаточно диким Frameworkом - говорю только о стандартном. Справедливости ради, скажу что навесив на ASP.NET функционально тяжелые компоненты (Telerik & C) получались еще те тормоза.
Насчет Сильверлайта вопрос неоднозначный, да 2.0 Бета сыровата, да все еще сильно отличается от полного WPF, но попробовав на тестах последний был приятно поражен.
Да пока только под Windows, да загрузка похлеще флекса, но работает и очень очень шустро именно для DATA Entry приложений - большинство из тех что делается для внутренней сети. Плюс опять же что фирмы компонентые очень тянутся и к WPF, и к Silverlight.
Да анимация и 3д поддержка (в Flash Player 10), но посмотрите на http://bubblemark.com/ хотя для бизнес аппликации это и не так важно.

А еще, если вам важна кросс-платформенность, обращаю внимание аудитории на то, что под линукс-системами во флекс-приложениях есть проблемы с кириллицей. Отображается она нормально, а вот ввод русских букв не работает... В поля вставляются зюквы. Решения мы пока так и не нашли.

Flex 4 выйдет не раньше чем через год, или "готовь сани летом" ?

Re: Flex 4 выйдет не раньше чем через год, или "готовь сани летом" ?

Недавно где то проскальзывал аносик по этому поводу (к сожалению ссылочку не сохранил),
Но сроки указаны меньше года.