Pull to refresh

Flex 3 vs. Silverlight 3 в Enterprise разработке

Reading time 7 min
Views 1.6K
Original author: Alex Vandenberg

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

Имея опыт разработки enterprise ПО на .NET платформе фактически с ее зарождения, я недавно сделал перерыв и потратил несколько месяцев на работу с очень большими Flex приложениями.

Rich Internet Applications (RIAs) взрослеют. Adobe создала свое Flash предложение более ориентированное на разработчиков – Flex. Microsoft еще недавно пришло на рынок с Silverlight.

По моему мнению, у Adobe за плечами мощное дизайнерское портфолио с отлично выглядящими приложениями. Microsoft и .NET платформа является лидером для разработки бизнес приложений, что наложило отпечаток на Silverlight, где бизнес функциональность более важна, чем вид.

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

Языки — C# vs. Actionscript


C# полностью объектно-ориентированный язык программирования, который в разработке бизнес-приложений занимает лидирующие позиции… Actionscript был первоначально скриптовым языком для Flash плеера, который притерпел изменения в Actionscript 3. Как объектно-ориентированный язык ему не хватает массы особенностей, которые Java или .NET разработчики принимают как само собой разумеющееся. Некоторый отличия я перечислю:

C#
  • Тип данных Decimal
  • Поддержка потоков
  • Генерики
  • Перегрузка методов
  • Перегрузка операторов
  • Структуры и Перечисления
  • Приватные конструкторы
  • Абстрактные ключевые слова
  • Лямбды и Linq
  • Публичные геттеры/приватные сеттеры
  • Автоматические свойства
  • Инициализаторы объектов
  • Безоговорочная типизация переменных

Actionscript:
  • Динамические классы и типы
  • События в Actionscript связываются через String, что может привести к проблемам в рефакторинге.
  • Внутренние модификаторы доступа кажутся слегка бессмысленными, по сравнению с реализацией в c#.

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

Известно, что Flex не хватает поддержки decimal-типов, особенно остро эта проблема заметна при разработке финансовых приложений. Математика с плавающей запятой, чаще всего, недостаточно точна для финансовых расчетов, об этом можно прочитать тут. FXComps принес во Flex свою реализацию decimal, но когда я произвел тесты производительности, я нашел, что деление decimal было в 3000 раз медленнее, чем деление float. Decimal умножение в 650 раз медленнее, чем float умножение. Честно говоря, decimal расчеты медленнее float и в C#, но не в таком масштабе, как здесь. Этого пункта должно быть достаточно для людей, которые рассматривают создание финансовых приложений, чтобы иметь серьезные сомнения относительно пригодности Flex.

В результате этого и других недостатков Actionscript компилятор менее эффективен в определении проблем в момент компиляции. Компиляция медленнее, чем у C# (Flex’у нужно 2 минуты на 100 000 строк кода). Проще говоря — Actionscript работает гораздо медленнее C#.

Не касаясь самого языка, можно заметить, что у C# есть .NET Framework, многое из которого доступно в Silverlight. В этом плане Flex/Actionscript нужно многое еще реализовать.

MXML vs. XAML


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

Silverlight больше способствует разделению между кодом и разметкой, с partial классами предлагает более чистую code-behind модель. Flex разрешает размещать скриптовые блоки в MXML файле, что приводит к раздуванию файлов UI разметки с презентационной моделью кода.

Компоненты фреймворка


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

Спросите любого Flex разработчика, который работал с внутренностями Advanced DataGrid, что он думает? (описание проблемы). Я видел, что люди вручную делали фокус элемента управления, обрабатывая tab события, так же реализовывали в коде работу скролбара в combobox’ах в grid’ах. Выходит так, что как только требуется небольшое усложнение функциональности, сложность кода во Flex растет экспоненциально.

Microsoft проделал хорошую работу впитав некоторые фичи с Flex. Тем не менее, существуют вещи, которых не хватает в Silverlight: запись видео и аудио, печать.

Сторонние компоненты


Тут у Microsoft особенно хорошо. Посмотрите на предложения от Infragistics, Syncfusion, Telerik. Используя эти предложения, вы можете быстро создать мощный UI, не написав, почти, никакого кода.

У Flex ‘а так же есть коммерческие и open source предложения, например ILOG Elixir from IBM. Но существуют компании, которые разрабатывают компоненты для Microsoft годами. У Flex предложения более ограничены.

Шаблоны и Практики, Фреймворки и Инверсия управления(IoC)


Silverlight имеет ряд фреймворков, которые можно сразу взять с полки: Composite WPF, CLSA.net, Spring.net. Использование таких фреймворков может значительно увеличить продуктивность разработчика, не только из-за установки повторяющихся шаблонов для написания согласованного и поддерживаемого кода, но это также подразумевает много самого сложного кода, который вам пришлось бы написать в проекте, который уже реализован для вас.

Опять таки, у .NET несколько отличных IoC фреймворков, которые могут уменьшить зависимости кода. Один из моих любимых фреймворков – Google Autofac. И хотя Actionscript продвигается в этом направлении, он все же остается сильно позади C# в этом плане. Spicefactory’s Parsley хорош, но требует больших конфигурационных файлов, как и Spring, фанатом которых не являюсь. У Adobe есть LifeCycle ES, который много чего предлагает, хотя иногда накладывая определенные ограничения.

IDE/инструменты рефакторинга


В больших проектах IDE может сохранить массу времени разработчика и следовательно денег. Обратно же, не стабильная IDE с ограниченными возможностями приводит к задержкам в проектах.

Это одна из областей, где Silverlight является лидером. Visual Studio 2008 превосходная IDE, особенно при сочетании с инструментами рефакторинга, как Resharper.

FlexBuilder и Eclipse имеют определенные недостатки, включая:
  • Фактически никакой поддержки рефакторинга. При объемном коде, попробуйте насладиться удобством поиска или переименованием, вам придется убить вашу IDE и перегрузить, хотя можете подождать минут 10, пока не произойдет переполнения памяти.
  • Отладчик. Flex Builder 3 не имеет базовых вещей, таких как условные контрольные точки и может только наблюдать за простыми выражениями. Условные контрольные точки будут в Flex Builder 4, но это еще раз подчеркивает на пропасть между VS и FB. VS2010 предоставит нам новое поколение фич, таких как Historical Debugging, в том время, как FB4 наконец-то добавит нужный функционал, который должен быть в любой IDE 1-ой версии.
  • Отсутствие интегрированного юнит тестера, по сравнению с предложениями MS Test или Resharper.


Юнит тестирование/mocking


Способность Flex к юнит тестированию удовлетворительная. Лично я считаю, что проекты могут погрязнуть в трясине с выбором таких инструментов в этой области. Тем не менее, C# обладает лучшим выбором moq-библиотек.

Юнит тестирование в C# с использование Visual Studio может стать более эффективным, если использовать такие интегрированные инструменты как MS Test или Resharper – достаточно выбрать методы или класс для тестирования и результат мы увидим в IDE. Если тест неудачный, достаточно нажать на нем, и он откроет неудачный тестовый метод. Если вам нужно протестировать только маленькую часть вашего Flex приложения, вы должны создать отдельный тестовый класс для запуска, определить тестовые условия, перекомпилировать и затем запустить проект. Если тест неудачный во Flex Unit, вы должны сделать пометки неудавшихся тестов и вручную найти их в IDE.

Да мы можем тестировать во Flex, но это сложнее и занимает больше времени.

Профайлинг


Инструмент профайлинга в Flex Builder весьма скудный и нет никаких сторонних альтернатив. Статистика производительности берется со старта приложения, а не между двух с слепков.

Насколько я знаю, сейчас еще не существует профайлера для Silverlight, тем не менее довольно просто конвертировать ваш код в WPF и после этого использовать инструменты профайлинга, мой любимый — dotTrace. Можно использовать Aqtime и DevPartner.

Примеры кода и документация


99% того, что вы захотите сделать в C# уже реализовано, 90% и более было описано в интернете. Комьюнити .NET разработчиков процветает. Если вы застряли, то потратив 5 минут на google или просмотрев MSDN – вы найдете ответ. Flex Livedocs же обладает гораздо меньшим набором материалов, чем MSDN.

Опыт разработчиков


Вообще, Flash/Flex разработчики владеют многолетним опытом создания приложения с приятным интерфейсом, но они не всегда пишут надёжный поддерживаемый код.

Так же, существует изобилие C# разработчиков с многолетним опытом написания enterprise приложений, но большинство их интерфейсов для пользователя бедны.

Естественно существуют исключения в обоих случаях. Я знаком с несколькими превосходными Flex разработчиками.

Установочная база


Flash Player установлен на 99% компьютерах. Если вы желаете охватить, как можно больше пользователей используя легкое приложение, то Flex/Flash очевидный выбор.

Для enterprise приложения это не достаточно весомый аргумент. В общем, если клиент купит ваше приложение, просьба о установке Silverlight не является слишком сложной или требовательной. Многие корпорации сейчас включают Silverlight, как часть их стандартного инсталлятора.

Резюме


В конечном счете, для меня выбор падает к тому, чего вы пробуете достичь. AНа данный момент, если внешний вид приложения — это то, что вас больше всего заботит, то скорее всего вам подойдет Flex. Однако, если вы собираетесь разрабатывать сложный бизнес функционал и так же заинтересованы в использовании money типа то лучше всего вам подойдет Silverlight. Это обусловлено главным образом результатом кода, который вы получаете в Siverlight проекте: простой, высокоуровневый, более поддерживаемый и чистый. С ростом сложности очень важно иметь структурированный базовый код.Без этого количество ошибок и регрессия будет только расти и обернется в лишние затраты.

Я годами разрабатывал с C# и получал удовольствие. Перейдя на Flex, у меня было такое ощущение, что мне связали руки за спину. Это расстраивает, что среда предоставляет лишь маленькую крупицу из того, чего можно было бы достичь. Говоря это, я признаю, что Flex приложения самые приятно выглядящие приложения, которые я видел.

Выражаю особую благодарность XaocCPS за корректировку перевода.
Tags:
Hubs:
+18
Comments 136
Comments Comments 136

Articles