Сообщений 2 
Оценка 0 
Оценить 
| Сообщений 2 Оценка 0 Оценить
|
Насыщенные интернет-приложения (Rich Internet Applications) сегодня всё чаще заменяют полноценные настольные приложения, не имея при этом недостатков последних – RIA-приложение не требует установки, и для его работы достаточно лишь браузера.
Цель данной статьи – рассказать об особенностях разработки приложений RIA с помощью технологий компании Microsoft , а также поделиться опытом автора по созданию подобных коммерческих приложений. Рассматривается классическая трехзвенная архитектура, состоящая из слоя данных, слоя прикладной логики и клиентского слоя. Клиентский слой в данном случае – это Silverlight-плагин для браузера либо клиент HTML5; слой прикладной логики – ASP.NET-сайт, на котором размещены Web-сервисы; слой данных – это СУБД MS SQL Server, а также система объектно-реляционного отображения (ORM).
В трехзвенной архитектуре главным элементом является, пожалуй, слой данных. Здесь хранятся бизнес-данные, ради доступа к которым создавалась вся система. На слой данных часто приходится наибольшая по сравнению с другими слоями вычислительная нагрузка. Проектирование системы начинается с проектирования объектной модели, которая также отражается в слое данных в виде БД. Поэтому выбор технологии ORM очень важен – он может как облегчить разработку и сопровождение, так и существенно осложнить их. Итак, что же выбрать?
На сегодняшний день Microsoft предлагает для платформы .Net по крайней мере три технологии доступа к данным. Рассмотрим каждую из них.
ADO.Net – это набор классов, предоставляющих службы доступа к данным. ADO.NET предлагает богатый набор компонентов для создания распределенных приложений, совместно использующих данные [3]. Данная технология очень популярна, т. к. она надежна и используется уже много лет. Кроме этого, для ADO.Net существует большое количество провайдеров данных, поэтому в качестве СУБД можно использовать различные продукты – MS SQL Server, Oracle Database, MySQL, FirebirdSQL и т. д. ADO.Net соответствует паттерн Table Data Gateway (шлюз к данным таблицы), описанный М. Фаулером [25]. Посмотрим, как работает ADO.Net.
Доступ к объектам базы осуществляется путем передачи на сервер кода SQL, команд запуска хранимых процедур или функций. При использовании этой технологии для каждой операции выборки, вставки, удаления или изменения строк в таблицах, как правило, пишется своя хранимая процедура, которую в нужный момент запускают с помощью классов ADO.Net. Это упрощает обслуживание системы в тех случаях, когда доступен лишь сервер БД и нет возможности изменить код на клиенте. К сожалению, при этом можно изменить только логику хранимой процедуры, а не сигнатуру (количество и тип параметров), поскольку в последнем случае процедура не будет совместима с вызывающим её кодом. Программисту требуется написать не только логику работы с базой в виде триггеров, функций и процедур, но и методы для работы с этими объектами базы в коде приложения. Кроме этого, необходимо реализовать некоторое количество классов (т. н. сущностей), с помощью которых будет выполняться дальнейшая логика работы с данными - отображение значений в таблицах пользовательского интерфейса, сериализация в xml на Web-сервисе или запись в файл. Чтобы упростить код, который выполняет обмен данными с базой, можно и нужно обобщать его – писать интерфейсы, абстрактные классы, различные универсальные методы. Однако чем абстрактнее такая система классов, тем больше времени нужно на её проектирование и разработку, что в общем делает дороже весь проект. Будут ли оправданными эти траты? Безусловно, если на разработку проекта выделены большие средства, а также сроки выполнения велики и особенно в тех случаях, когда во главу угла ставится скорость работы. Технология ADO.Net позволяет гибко выстроить работу с базой, т.к. SQL-запросы пишутся вручную, и их можно очень хорошо оптимизировать, тем самым повышая скорость выполнения запросов и уменьшая сетевой трафик.
Кроме описанных выше преимуществ, ADO.Net имеет и существенные недостатки. Самый главный – необходимость написания большого количества SQL-кода вручную. Кроме того, возникает необходимость ручного разбора результатов запросов, а также самостоятельного создания классов бизнес-сущностей. Наконец, отсутствует возможность проверять корректность кода в процессе компиляции – любая синтаксическая ошибка в названии сущностей может быть выявлена только при непосредственном выполнении кода, что замедляет процесс отладки и тестирования.
В этой технологии модель данных реляционной базы данных сопоставляется с объектной моделью, выраженной в языке программирования разработчика. При запуске приложения LINQ to SQL преобразует запросы LINQ из объектной модели в SQL и отправляет их в базу данных для выполнения. Когда база данных возвращает результаты, LINQ to SQL преобразует их обратно в объекты, с которыми можно работать на собственном языке программирования [4]. LINQ to SQL соответствует паттерн Active Record (активная запись), описанный М. Фаулером [26]. Для генерации набора классов, соответствующих сущностям БД, обычно используется встроенный в Visual Studio инструмент – ORM-дизайнер. С его помощью можно автоматически создать классы языка программирования (C# или Visual Basic .Net), которые можно использовать в дальнейшем для любых нужд. Все операции вставки, обновления, удаления записей в таблицах БД можно делать при помощи специального класса LINQ to SQL – контекста. Фактически, работа с базой данных превращается просто в работу с набором классов, где запросы формируются на языке C# (VB.Net) с использованием лямбда-выражений LINQ to SQL. Плюсы такого подхода – упрощается отладка, нет необходимости писать хранимые процедуры, все данные из базы доступны в виде сущностей и коллекций сущностей, которые могут быть сразу привязаны к компонентам пользовательского интерфейса, либо сериализованы для дальнейшей передачи через Web-сервис.
Вместе с этим, применение LINQ to SQL накладывает на систему некоторые ограничения – технология не поддерживает серверы БД, отличные от MS SQL Server, а также зачастую формирует не совсем оптимальные SQL-запросы.
Entity Framework — позволяет разработчикам создавать приложения для доступа к данным, работающие с концептуальной моделью приложения, а не напрямую с реляционной схемой хранения. Цель состоит в уменьшении объема кода и снижении затрат на сопровождение приложений, ориентированных на обработку данных. [5]. Технология схожа с LINQ to SQL, но имеет некоторые отличия. Entity Framework, в отличие от LINQ to SQL, поддерживает работу с СУБД, отличными от MS SQL Server [6, 7], в частности, с Oracle Database [8]. Технологию можно сопоставить с паттерном Domain Model (модель области определения), описанный М. Фаулером [27]. Кроме этого, LINQ to Entities позволяет использовать модель сущностей, которая значительно отличается от соответствующей модели данных [6] [7], в то время как LINQ to SQL создает жесткую привязку генерируемых классов к таблицам базы данных (одна таблица – один класс). Фактически, структура модели LINQ to Entities не привязана к источнику данных – необходимо лишь проставить соответствия свойства генерируемых классов с реальными столбцами таблиц или представлений БД. Вместе с тем, LINQ to SQL позволяет использовать собственные классы сущностей, наследоваться от интерфейсов или базового класса сущностей. В Entity Framework такой возможности нет.
Можно сделать вывод, что использовать Entity Framework разумно в больших проектах со сложной структурой данных, а также в случаях, когда необходима поддержка сторонних СУБД (не MS SQL Server).
Как показывает опыт автора, времени на проектирование и написание кода, как правило, всегда мало – и архитекторы, и разработчики ищут пути наименьшего сопротивления. В большинстве ситуаций технология ADO.Net себя не оправдывала, и её применение в некоторых проектах было обусловлено совместимостью с ранее написанным кодом. Однако в силу достаточного большого возраста технологии, у разработчиков накоплено значительное количество наработок – фреймворков, оберток, вспомогательных классов, применение которых несколько сглаживает недостатки ADO.Net. В новых же проектах всегда использовались технологии LINQ to SQL или Entity Framework, в которых возможность автоматического создания классов из сущностей БД значительно уменьшило время разработки, сократило размер написанного кода, а также сделала его более понятным. Хорошо зарекомендовал себя комбинированный способ – на ASP.Net сайте системы, где размещается приложение Silverlight, использовать Entity Framework, т. к. часто необходимо создавать сложные сущности на основе уже имеющихся, и очень удобно редактировать модель прямо в ORM-дизайнере. Напротив, для служб, которые выполняют в фоне анализ данных и работают напрямую с БД, проще обойтись технологией LINQ to SQL, сущности которой жестко привязаны к сущностям базы.
Определившись с технологиями доступа к данным и СУБД, необходимо выбрать также технологию обмена данными между сервером и клиентским приложением Silverlight – платформу Web-сервисов. На сегодняшний день разработчикам на .Net доступно несколько таких платформ, их выбор, как и в случае с выбором технологии доступа к данным, зависит от поставленных перед проектом задач. К выбору платформы Web-сервисов необходимо отнестись очень внимательно, поскольку от него во многом зависит успех разработки всей системы. Итак, рассмотрим основные технологии Web-сервисов, предложенные компанией Microsoft.
Windows Communication Foundation (WCF) представляет собой новое поколение коммуникационной инфраструктуры Microsoft, построенной на основе архитектуры Web-сервисов. Расширенная поддержка Web-сервисов в Windows Communication Foundation обеспечивает безопасную, надежную транзакционную систему передачи сообщений с возможностью реализации гетерогенных систем[9].
С точки зрения разработчика технология представляет собой набор классов, экземпляры которых размещаются в каком-либо процессе Windows. Чаще всего для этого используется процесс Web-сервера (IIS). При этом запрос к сервису осуществляется через URL, а передача – либо в формате xml, либо в двоичном виде. Для работы механизма необходимо создать в серверном проекте сервис WCF, а в клиентском (в данном случае это приложение Silverlight) – добавить ссылку на этот Web-сервис. Чтобы осуществить обмен данными между клиентом и сервером, необходимо, чтобы содержащие эти данные классы могли быть сериализованы. Как следствие, передать через сервис класс, сгенерированный, к примеру, дизайнером сущностей Entity Framework, нельзя. Для обхода этого ограничения нужно написать вспомогательный класс, у которого кроме всего прочего, передаваемые свойства помечены специальным атрибутом – DataContract (см. [11]). Помимо этого, если передаваемый класс содержит ссылку на еще один класс данных, то он также должен быть сериализуем. В результате для того, чтобы иметь возможность передавать данные, необходимо фактически переписать вручную структуру сущностей, сгенерированных дизайнером ORM. Такой подход оправдан при небольшом наборе сущностей, которые подлежат передаче через сервис, а также в сервисе, который вообще не использует классы данных, а служит лишь для управления некоторой серверной логикой (к примеру, получение серверного времени). Таким образом, при наличии сложной системы сущностей использование сервисов WCF значительно замедляет создание и доработку системы. Однако использование этой технологии оправдано в тех системах, где в основном требуется передавать созданные вручную классы или команды.
Службы WCF Data Services (которые раньше назывались «ADO.NET Data Services») – это компонент платформы .NET Framework, с помощью которого можно создавать службы, использующие протокол Open Data Protocol (OData) для передачи и получения данных через Интернет или интрасеть с помощью семантики REST. Службы OData предоставляют данные в качестве ресурсов, доступ к которым осуществляется с помощью URI. Доступ и изменение данных производится с помощью таких стандартных команд HTTP, как GET, PUT, POST и DELETE. В службах OData используются соглашения связи сущностей модели Entity Data Model для предоставления ресурсов в виде наборов сущностей, связанных с помощью сопоставлений [12].
При использовании этой технологии роль слоя приложений фактически сведена к минимуму. Web-служба выступает лишь как посредник между источником данных и клиентским приложением. В результате сложность разработки уменьшается – с клиентского приложения можно выполнить практически любой запрос к базе данных посредством WCF Data Services. Такой подход удобен в тех случаях, когда в клиентском приложении требуется лишь отображать данные соответствующих таблиц БД, а обработка данных на сервере минимальна или полностью отсутствует. Примером таких систем могут служить информационные панели в общественных местах – расписания транспорта, электронные очереди в банках и так далее. Однако в случаях, когда на сервере приложений планируется обрабатывать получаемые и возвращаемые Web-сервисом данные, либо когда Web-сервис должен содержать методы, не связанные с обменом данных с БД, применение данной технологии становится невыгодным..
WCF RIA Services. Службы WCF RIA упрощает разработку многоуровневых решений класса RIA, таких, как приложения Silverlight. Типичной проблемой при разработке многоуровневого решения RIA является согласование логики среднего уровня и уровня представления. Чтобы обеспечить максимальное взаимодействие с пользователем, клиент Службы RIA должен учитывать логику приложения, которое находится на сервере. Однако было бы нежелательным разрабатывать и поддерживать одну и ту же логику как на уровне представления, так и на уровне логики приложения. Службы RIA решает эту проблему, поскольку в составе платформы имеются компоненты, инструменты и службы, обеспечивающие доступ клиента Службы RIA к логике приложения на сервере без необходимости вручную дублировать эту программную логику. Можно создать клиент Службы RIA , учитывающий бизнес-правила, и при каждой компиляции решения эта логика будет автоматически обновляться на клиенте. На рис. 1 показана упрощенная версия многоуровневого приложения. Службы RIA посвящены в основном решению задач в прямоугольнике между уровнем представления и уровнем доступа к данным (DAL) и позволяют упростить разработку многоуровневого решения с клиентом Службы RIA [13].
Рис. 1. Схема работы RIA
Как можно видеть, преимуществами технологии является автоматическая генерация сериализованных классов на основе контекста данных LINQ to SQL или LINQ to Entities на сервере и клиенте, а также автоматическая синхронизация серверного и клиентского контекстов при построении проектов. Помимо этого, существует возможность создавать пользовательские методы, возвращающие созданные вручную сущности (члены классов должны быть помечены атрибутом сериализации, как в WCF Services). Таким образом, технология соединяет в себе преимущества WCF Services и WCF Data Services. Помимо этого, необходимо отметить легкость, с которой можно создать контекст аутентификации. В распоряжении разработчика оказывается функциональный шаблон сервиса аутентификации, код которого также автоматически синхронизируется с кодом клиентского приложения, что значительно упрощает разработку.
WCF RIA Services использует для обмена данными с клиентами Silverlight технологию SOAP, передавая данные в двоичном виде. Однако при обмене с остальными клиентами используется XML-формат SOAP для передачи данных [14].
Службы WCF RIA в настоящее время оптимизированы для работы с клиентом Silverlight в том смысле, что поддерживают автоматическое создание кода для учетной записи-посредника Silverlight. Однако служба домена может быть вызвана и из других клиентов .NET, таких как клиент ASP.NET [15]. Иными словами, технология была создана с учетом особенностей работы с Silverlight-клиентом.
Среди упомянутых технологий Web-сервисов для RIA-клиентов по мнению автора следует предпочесть WCF RIA Services. По сравнению с другими упомянутыми технологиями, использование этой технологии позволяет сократить время разработки за счет автоматической генерации системы сущностей на клиенте с возможностью отслеживания изменений в этой системе. В данной статье не рассматривалась ASP.NET Web Services, так как эта технология сохраняется лишь для обеспечения обратной совместимости с существующими приложениями и её не рекомендуется использовать для разработки новых приложений [15].
По мнению автора, программирование клиентской части часто занимает гораздо больше времени, чем разработка серверной логики и баз данных. Главная причина состоит в том, что именно на клиентскую часть заказчик обращает внимание в первую очередь. Можно создать хорошо оптимизированную БД, оптимизировать запросы или хорошо защитить систему от взлома, но если дизайн интерфейса плох и нефункционален, такой продукт имеет низкие шансы на внедрение. Учитывая важность этой части системы, следует отводить на ее создание как можно больше проектного времени. Кроме того, очень важно тестировать удобство интерфейса – эту операцию следует поручать тестировщикам, так как они не принимали участие в разработке и поэтому они могут непредвзято оценить удобство использованных дизайнерских решений в пользовательском интерфейсе.
Silverlight становится все более популярной технологией для создания клиентской части «насыщенных» web-приложений (Rich Internet Applications). На момент написания статьи процент её проникновения на рынок составляет около 64% [1]. Технология предоставляет широкие возможности по отображению анимации, визуальных эффектов, видео, аудио и графики с помощью web-браузера. Кроме этого, в анонсированной пятой версии появится поддержка аппаратного ускорения для отображения трехмерной графики и видео [2]. Для разработчика возможности не менее впечатляющие – это использование языков XAML и C# на платформе .Net в среде Visual Studio 2010, удобное кодирование видео в Expression Encoder, а также визуальное проектирование интерфейсов любой сложности в программах Expression Blend и Expression Design.
Несмотря на то, что программисту на Silverlight дается в помощь мощный арсенал инструментов, зачастую разработка протекает далеко не так гладко, как хотелось бы. Возьмём, к примеру, стили и шаблоны Silverlight. По-настоящему оценить мощь и удобство этих технологий можно только после осознания того, как они работают. Здесь путем переопределения стиля компонента можно превратить кнопку в отмечаемое поле (checkbox) или таблицу данных (datagrid), отобразить видео в качестве фона элемента управления или поместить графики в ветви дерева - возможности для создания интерфейса ограничиваются только фантазией разработчика. Вполне вероятно, что эти возможности не были ранее знакомы разработчику и их изучение потребует достаточного длительного времени. Однако после их освоения станет возможным быстрая разработка качественных web-приложений, которые по функциональности во многом не будут уступать настольным.
На данный момент производителем представлена финальная версия Silverlight 5, однако здесь будет идти речь о версии Silverlight 4, поскольку описываемые в статье особенности разработки одинаково актуальны для обеих версий технологии. Тем не менее, необходимо отметить новшества, реализованные в пятой версии – отладка привязок данных в разметке XAML, возможность выполнения нативного кода на клиентской машине (P/Invoke), аппаратное декодирование H.264 медиа, векторная печать PostScript, улучшенные графические возможности с поддержкой 3D. [34]
В Silverlight существует мощная система создания пользовательских интерфейсов практически любой сложности – разработчику дается возможность настроить вид любого элемента с помощью стилей и шаблонов. Все элементы управления, которые существуют в Silverlight – кнопки (buttons), таблицы (datagrids), списки (listboxes) и т. д., – уже описаны соответствующими стилями по умолчанию. Эти стили хранятся в динамических библиотеках (.dll), то есть там же, где и классы самих элементов управления. Разработчик может настраивать вид элементов с помощью правки этих стилей. Для таких операций удобнее всего использовать Microsoft Expression Blend [16] – он предоставляет возможность править оригинальный стиль элемента в визуальном редакторе, и сохранять измененный стиль отдельно в виде .xaml-разметки. Таким путем можно придать элементу управления необходимый дизайн, настроить компоновку или усовершенствовать его функциональность. Данный подход используется в WPF (Windows Presentation Foundation) [28], однако технология WPF предназначена, в отличие от Silverlight, для создания настольных приложений.
Опыт автора по работе с элементами управления Silverlight показывает, что существует множество мест интерфейса, где оригинальный дизайн компонентов довольно неудобен. К примеру, в дереве (TreeView) из пакета Silverlight Toolkit [17] при выделении элемента подсвечивается только надпись (рис. 2а), а не вся строка (рис. 2б)
а)
б)
Очевидно, что вариант, изображенный на рис. 2,а неудобен тем, что для выделения элемента дерева нужно нажать кнопку мыши непосредственно на тексте ветви дерева, в отличие от варианта на рис. 2,б, где для этого достаточно нажать на любую точку нужной строки.
По опыту автора, неудобства интерфейса, подобно описанному выше, далеко не всегда очевидны на стадии разработки, поскольку в ходе отладки запуск приложения происходит большое количество раз, и развивается своего рода привыкание к такому виду элементов. Как следствие, на подобные моменты часто не обращают внимание. Однако человек, впервые начавший пользоваться системой, замечает такие недочеты практически сразу. Исходя из этого, не стоит поручать разработчику проверку удобства пользования интерфейсом, т. к. большинство ошибок дизайна для него будут неочевидны.
Разработка системы редко обходится без существенного изменения оригинального дизайна визуальных компонентов. Более того, существует соблазн написать «с нуля» свою систему стилей для каждого компонента с использованием, к примеру, корпоративных цветов. Однако следует иметь в виду, что эта работа может занять большое количество времени и не оправдать возложенные ожидания, особенно если в команде нет профессиональных дизайнеров. В этом случае за основу стоит брать оригинальный дизайн компонентов, а изменять лишь показавшиеся неудобными моменты, поскольку визуальные стили компонентов «по умолчанию» основаны на опыте их использования, в то время как созданные «с нуля» – еще нет. Однако если во главу угла в проекте ставится именно дизайн пользовательского интерфейса, имеет смысл потратить некоторое количество проектного времени на создание своего собственного стиля оформления для всех визуальных компонентов. Как результат, можно получить уникальный, удобный и красивый дизайн, который положительно отразится на репутации системы, что существенно облегчит ее внедрение в организациях заказчиков.
В сети Интернет существует множество ресурсов, где различные стили и шаблоны элементов управления Silverlight и WPF выложены в открытом доступе. Как правило, это ресурсы компаний, продающих собственные компоненты для различных технологий – ASP.Net AJAX, WinForms, jQuery, Silverlight, WPF и т. д. Стоит выделить некоторые из них:
Приведем сравнительную таблицу перечисленных компонентов.
|
Критерий |
Silverlight Toolkit |
Telerik |
Infragistics |
DevExpress |
|
Цена за компоненты Silverlight, годовая подписка |
0$ |
1000$ |
995$ |
900$ |
|
Цена за полный набор компонентов, годовая подписка |
0$ |
1499$ |
1295$ |
2200$ |
|
Техподдержка |
- |
+ |
+ |
+ |
|
Последняя версия Silverlight |
Декабрь 2011 года |
3 квартал 2012 года |
Октябрь 2012 года |
Ноябрь 2012 года |
|
Количество компонентов Silverlight |
38 |
~60 |
~65 |
~55 |
|
Barcode Reader |
- |
+ |
+ |
- |
|
Formula Editor |
- |
- |
+ |
- |
|
OLAP Data Mining |
- |
- |
+ |
+ |
|
Gantt Control |
- |
+ |
+ |
- |
|
HTML Viwer |
- |
+ |
+ |
- |
|
Undo/redo framework |
- |
- |
+ |
- |
|
Diagrams |
- |
+ |
- |
- |
|
Heatmap |
- |
+ |
- |
- |
|
Regular expression control |
- |
- |
- |
+ |
|
Math Control |
- |
- |
+ |
- |
|
Компоненты для HTML5 |
- |
+ |
+ |
- |
|
Собственные стили и шаблоны |
+ |
+ |
+ |
+ |
Перечисленные компании и сообщества создали немало компонентов для удобного представления информации, в частности, таблицы данных (datagrids) с удобной сортировкой и группировкой, графики (charts), различные шкалы, списки, ползунки и панели навигации. Использование в системе таких продуктов позволяет в короткие сроки создать очень мощный, красивый и удобный пользовательский интерфейс, так как все компоненты тестируются большим количеством пользователей, и за несколько лет разработки эти компоненты вобрали в себя большой опыт их использования. Платность таких продуктов не должна смущать – заплатив в среднем около 1000$ за текущую версию компонентов для Silverlight, можно сократить время разработки и сделать намного более функциональный дизайн. Кроме того, различные пожелания заказчика, которые рано или поздно у него возникают, можно также реализовать гораздо быстрее и качественнее, что повышает доверие к компании-разработчику. Таким образом, выгода от использования сторонних компонентов практически всегда окупает их стоимость. Однако следует отметить, что при использовании сторонних продуктов нужно быть готовым к ошибкам, которые могут обнаружиться в ходе их использования. Очень часто такие ошибки уже были обнаружены кем-то из пользователей, о чем можно узнать на сайте производителя – в форумах или блогах. Как правило, такие ошибки закрываются в следующей версии продукта.
В Silverlight, как и в любом RIA-клиенте, обмен данными асинхронный. Это обстоятельство часто значительно снижает скорость разработки по сравнению с обычными настольными приложениями, которые используют архитектуру «клиент-сервер». При асинхронном обмене данными запуск запроса к Web-сервису и получение результата выполняется не по очереди, а с некоторой задержкой, при этом после выполнения запуска запроса текущий поток продолжает выполняться, не дожидаясь ответа от сервера. Ответ приходит в любое время, а обработкой его результатов (к примеру, коллекции с данными) должен заниматься делегат, который был подписан на событие ответа по этому запросу. Однако в ходе запроса могут возникнуть ошибки – исключение в коде веб-сервиса, потеря связи с сервером, недоступность БД и т. д. При этом, в отличие от системы с синхронным выполнением запросов, исключение возникает не в методе запуска запроса, а передается как аргумент делегату. Как результат, отлавливать ошибки необходимо уже в двух местах – в коде старта запроса и в делегате завершения выполнения запроса. Конечно, сделать эту работу нетрудно, но, как показывает практика, запросов в системе может быть несколько десятков или сотен – при таком положении дел сильно возрастает сложность отладки. Чтобы решить проблему, нужно абстрагироваться от конкретных запросов, и написать систему классов, которая позволит легко обмениваться с Web-сервисом любыми типами данных. Такие классы значительно упростят расширение системы – добавление новых запросов будет требовать написания минимального количества кода. Безусловно, разработка упомянутой системы классов оправдана лишь для достаточно крупных систем, либо в случае разработки нескольких типовых проектов. Подобная система классов может являться клиентским фреймворком – он может быть использован повторно в других проектах на Silverlight.
Один из вариантов клиентского фреймворка предлагает паттерн MVVM – «модель-представление-модель представления» (Model-View-ViewModel). В 2005 году Джон Госсман (John Gossman), один из архитекторов WPF и Silverlight в корпорации Microsoft, рассказал в своем блоге об этом паттерне. MVVM совпадает с моделью презентации (PM) Фаулера в том плане, что оба шаблона содержат абстракцию представления, содержащую состояние и поведение представления. Фаулер ввел модель презентации как способ создания независимого от платформы пользовательского интерфейса абстракции представления, а Госсман предложил MVVM как стандартизированный способ использования основных функций WPF для упрощения создания пользовательских интерфейсов. В этом смысле MVVM – частный вариант более общего шаблона PM, приспособленный для платформ WPF и Silverlight [21].
Использование этого паттерна позволяет отделить логику приложения от графического интерфейса, что дает возможность разрабатывать то и другое независимо друг от друга. Описанные выше классы фреймворка могут служить базовыми моделями паттерна MVVM, и содержать весь набор типовых операций по асинхронной загрузке и отправке данных. С учетом того, что в Silverlight существует мощная система связывания данных (data binding), реализовать в Silverlight подобный паттерн довольно легко. Абстракция классов и применение MVVM сильно упростит будущую работу по расширению функциональности, добавлению новых сущностей и бизнес-логики. Начальное падение скорости разработки, связанное с проектированием абстрактных моделей, будет компенсировано скоростью последующей разработки новых модулей. Таким образом, использование MVVM тем более оправдано, чем больше сложность клиентской части системы.
При всех преимуществах Silverlight очевидным недостатком является отсутствие поддержки в операционных системах iOS и Android, а также частичная поддержка в Linux (посредством Moonlight [31]). Кроме того, для работы Silverlight требуется установить плагин к браузеру, что требует прав администратора. Эти обстоятельства сильно ограничивают распространение технологии. Однако Microsoft, как и многие другие гиганты IT-индустрии, делает ставку на еще один быстроразвивающийся продукт, который лишен вышеперечисленных недостатков – HTML 5.
В качестве клиента RIA может выступать и страница, написанная на HTML 5 [29] c использованием Java Script. В последнюю версию языка HTML вошли многие возможности, которые предоставляет Silverlight, например, отображение видео, холст (canvas), хранилище данных и т. д. Но, в отличие от Silverlight, вместо XAML используется HTML пятой версии, а вместо C#/VB.Net – JavaScript. HTML 5, как и язык Java Script, поддерживается практически любыми современными версиями браузеров. Однако поскольку стандарт HTML 5 все еще находится в стадии разработки, многие элементы языка носят экспериментальный характер, и не все браузеры могут полноценно с ними работать [30]. Такие проблемы достаточно сильно снижают выгоду от кроссплатформенности HTML 5, особенно при активном использовании новых элементов языка, но эти проблемы являются скорее временными и будут решаться по мере выхода новых версий браузеров. Наконец, новая версия HTML не лишена традиционного недостатка языка – необходимости учитывать при верстке страницы особенности различных браузеров с тем, чтобы страница везде выглядела одинаково.
Как и для Silverlight, для HTML5 выпущено много различных компонентов интерфейса – KendoUI от Teletik [32], Ignite UI от Infragistics [33] и т. д. Использование этих продуктов в проекте сильно упрощает разработку и расширяет возможности технологии. Однако, по мнению автора, даже используя эти компоненты, невозможно достичь той скорости разработки и тех возможностей, которые может дать использование Silverlight. В этой связи можно сделать вывод о том, какой клиент нужно выбирать для создания RIA-приложения. Если требуется кроссплатформенность или накладывается ограничение на использование плагинов к браузеру, то единственный выбор – HTML5. В других случаях более предпочтительна технология Silverlight.
В данной статье была предпринята попытка поделиться опытом автора по разработке RIA – приложений, использующих технологии Microsoft. Очень часто только после завершения работы над системой приходило понимание того, как следовало бы делать, а что было лишним, и каждый проект давал ценные знания о том, как разрабатывать быстрее, дешевле и качественнее. Для понимания принципов функционирования технологий необходимо тщательно следить за развитием продуктов, особенно при использовании Silverlight, где с каждой новой версией появляется большое количество новых возможностей, и одну и ту же задачу часто можно решить все более простым способом. Литературы по Silverlight на русском языке, особенно для версий 4,5 немного. Одна из них – книга С. Байдачного [23]. Англоязычной литературы намного больше, например, книги издательства Apress. Ответы на многие вопросы по разработке RIA-приложений можно найти и в сообществе TechDays [24] – здесь есть большое количество докладов и обзоров для разработчиков.
Безусловно, многие вопросы, затронутые в статье, можно решить иначе. Однако во многих ситуациях выбор был обусловлен опытом использования той или иной технологии, с учетом трудностей, на преодоление которых ушло значительное количество времени. Поэтому если информация из этой статьи поможет читателю хоть немного сократить время разработки какого-либо RIA-приложения, автор будет считать свою задачу выполненной.
| Сообщений 2 Оценка 0 Оценить
|