Разработка бизнес-приложений с использованием Silverlight

Создать новую статью

12.10.2009 14:00


Аннотация

Данная статья посвящена рассмотрению вопросов создания бизнес-приложений на основе технологии Silverlight. Рассматриваются следующие вопросы:

  • применение существующих шаблонов бизнес-приложений к технологии Silverlight;
  • тестирование Silverlight приложений и техника разработки приложений через тестирование (TDD);
  • применение гибких методов разработки (Agile development: eXtreme Programming (XP), Scrum).

Введение

Этой весной я случайно наткнулась в интернете на интересную ссылку о возможности прохождения стажировки в Intel. Скачав список задач, я решила, что обязательно найду что-нибудь интересное для себя, однако, выбирать долго не пришлось: вторая же задача оказалась идеальным проектом для меня. А звучала она так: «Задача 2: Разработка интранет-приложения с использованием Silverlight». Заинтересовала она меня по двум причинам: во-первых, по своей трудовой деятельности я сталкивалась с технологией Silverlight, но, к сожалению, не было возможности подробно изучить её и попробовать, поэтому очень хотелось углубить свои знания в этой технологии и попробовать применить её. Во-вторых, прочитав описание задачи, я поняла, что речь пойдет о бизнес-приложениях. После окончания ВУЗа я видела себя именно в сфере разработки бизнес-приложений и опыт их создания это то, чего мне так не хватало как молодому специалисту. И конечно возможность посмотреть компанию Intel изнутри, пообщаться с людьми, которые там работают, научиться чему-то новому и перенять существующий опыт - это то, чего я не могла упустить. Поэтому недолго думая, я заполнила заявку на участие в Летней школе и так я оказалась в Intel Summer School 2009. Над проектом я работала вместе с Евгением Кречуном. Нашим менеджером и непревзойденным идеалом был Евгений Сорокин. В первый же день перед нами были четко сформулированы основная цель и задачи проекта.

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

  • Исследовать существующие шаблоны проектирования бизнес-приложений для создания хорошо масштабируемой и гибкой архитектуры бизнес-приложения.
  • Освоить технику разработки приложений через тестирование (Test Driving Development), которая позволяет писать более качественный код и снизить риск появления ошибок.
  • Научиться методам гибкой разработки (Agile development: eXtreme Programming (XP), Scrum).
  • Разработать прототип Silverlight-приложения; Мы были полны одержимого интереса и энергии и хотелось, как можно быстрее приступить к работе.

Разработка прототипа бизнес-приложения

Итак, основной нашей задачей было исследовать технологию Silverlight и определить насколько она подходит для создания бизнес приложений, а также разработать прототип такого приложения. Кодовое название нашего проекта - Dashboard. Основные его функции:

  • Сравнение программных проектов по заранее заданным характеристикам с использованием деловой графики.
  • Просмотр информации о программных проектах (общее описание и список разработчиков).
  • Просмотр и редактирование информации о разработчиках.

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

В успехе любого проекта немаловажную роль играет UI, он же - пользовательский интерфейс. И технология Microsoft Silverlight создана именно для созданий интернет и интранет приложений с богатым пользовательским интерфейсом - RIA (Rich Internet application). 10 июля 2009 в 18:00 по московскому времени Microsoft выпустила Silverlight 3 и Microsoft Expression Studio 3, именно эту версию Silverlight мы и решили использовать в нашей разработке. Помимо этого нам понадобились MS Visual Studio 2008 и Silverlight Toolkit.

Начали мы разработку нашего приложения с изучения существующих шаблонов проектирования бизнес-приложений. Для разработки нашего приложения мы использовали шаблон Model View Presenter - шаблон проектирования пользовательского интерфейса, который был разработан для облегчения модульного тестирования и отделения логики от отображения. Помимо шаблона проектирования, немаловажными оказался сам подход к проектированию, а именно ориентация на предметную область - Domain Driven Design, который заключается в следующем:

  • основное внимание при разработке должно уделяться предметной области и ее логике;
  • разработки в рамках сложных предметных областей должны базироваться на модели предметной области.

Сочетая MVP с основными принципами Domain Driven Design, мы в конечном итоге получили архитектуру приложения, приведенную на рисунке 1.

Архитектура приложения

Рисунок 1. Архитектура приложения

Как видно наша система состоит из двух основных частей: клиентской и серверной.

Клиентская часть представлена Silverlight приложением. Вообще SIlverlight - это кроссплатфоменный и кроссбраузерный плагин, а Silverlight приложение - это .xap файл (по сути дела тот же zip архив, содержащий все ресурсы и сборки приложения), выполняющийся в плагине Silverlight. На момент разработки нашего приложения существовало три типа проектов для Silverlight:

  • Silverlight Application - обычное приложение Silverlight.
  • Silverlight Class Library - библиотека классов Silverlight, этот тип проекта использовался для слоев: Presentation, Infrastructure, Domain.
  • Silverlight Navigation Application - приложение SIlverlight, поддерживающее навигацию, этот тип проекта использовался для слоя View.

Серверная часть представлена WCF сервисом, взаимодействующим с БД через соответствующий слой Data Access. Рассмотрим подробнее слои приложения:

Domain. Этот слой находится в центре нашего приложения и инкапсулирует в себе всю бизнес-логику и знания предметной области. Данный слой содержит все основные бизнес-сущности и бизнес-правила предметной области. В нашем случае классы Solution (программный проект), Measure (показатель), Developer (разработчик), SolutionProfile (профиль проекта) относятся именно к доменным объектам. Вполне естественно, что в приложении должен быть единый домен, поскольку все, что относится к бизнесу описано именно в этом слое. Однако в архитектуре нашего приложения присутствует два домена. Это связано с ограничением технологии Silverlight. Поскольку технология Silverlight работает на своей платформe Silverlight .Net Framework, которая является сильно урезанной версией полноценного .Net Framework, то совместное использование доменных объектов сборками Silverlight и .Net Framework без перекомпиляции невозможно.

Для разрешения данной проблемы и были созданы две сборки Domain: одна используется Silverlight сборками клиентской части, а вторая используется WCF сервисом, работающим под управление полноценного .Net Framework. Однако практически все не так сложно:

  • создаем одну сборку Silverlight Class Library;
  • создаем вторую сборку обычную .Net Class Library;
  • указываем у них одно и то же пространство имен;
  • создаем доменные классы в сборке Silverlight;
  • затем добавляем ссылки на доменные объекты из .Net Class Library.

В итоге, фактически мы имеем файлы с доменными объектами только в одном экземпляре, а компилируются они в разные сборки. Тем самым наши доменные объекты мы можем использовать как в клиентских сборках Silverlight, так и в WCF сервисе (сборке полноценного .Net Framework).

Presentation. Этот слой содержит в себе всю логику работы интерфейса. В этом слое содержатся классы презентеров (Presenters), которые управляют видами (Views). В этом же слое объявлены интерфейсы IViews, которые реализуются в слое View. Также здесь содержатся плоские объекты, так называемы Presenter Entities, которые обеспечивают более удобное представление доменных объектов для отображения. Вся логика работы интерфейса заложена в этом слое. Поскольку он отделен непосредственно от представления (View), и реализован в виде библиотеки классов, то данный слой идеально поддается модульному тестированию, что естественно является одной из главных особенностей и преимуществ шаблона MVP.

View. Этот слой представляет собой UI нашего приложения. В нем реализуются интерфейсы, объявленные в слое Presenter (IViews). Сам View содержит в себе минимум логики (Passive View), и имеет только простые свойства, для отображения данных.

Infrastructure. Данный слой содержит классы адаптеров, которые предоставляют и сохраняют доменные объекты по запросу презентеров. Разнообразие адаптеров скрывается от слоя Presenter одним общим фасадом (GOF Facade pattern), что делает работу со слоем Infrastructure очень простой и удобной. Сами интерфейсы фасада и адаптеров объявлены в слое Domain, а в слое Infrastructure содержится реализация этих интерфейсов.

Серверная часть реализована в виде WCF сервиса, который с помощью слоя DataAccess (в нашем случае в качестве ORM мы использовали LINQ to SQL) получает данные из BD, формирует доменные объекты и передает их в клиентскую инфраструктуру. Однако для того чтобы передать доменные объекты необходимо их сериализовать, то есть преобразовать из сложных объектов в строку, а на клиенте в слое Infrastructure соответственно десериализовать строку в доменные объекты. Для сериализации мы использовали класс DataContractSerializer, доступный как в полноценных сборках .Net, так и в сборках Silverlight, что очень важно при интеграции приложения, поскольку сериализация и десериализация доменных объектов происходит как в клиентских сборках, так и в серверных сборках.

Так как мы разрабатывали, используя TDD - разработку приложений через тестирование, то вопросам тестирования Silverlight приложений мы уделили значительную часть нашего рабочего времени и провели исследование в этой области. В итоге мы рассмотрели преимущества и недостатки двух основных платформ для тестирования: MS Unit Test Framework (встроенный в MS Visual Studio) и Silverlight Unit Test Framework. Попробовав обе эти платформы, мы сделали следующие выводы:

MS Unit Test Framework

  • Подходит для тестирования библиотек классов Silverlight (class libraries).
  • Для тестирования необходимо использовать системные сборки Silverlight (в частности заменять сборки System.Core на соответствующую сборки Silverlight System.Core).

MS Silverlight Unit Test Framework

  • Подходит для тестирования пользовательских контроллов, анимации непосредственно из браузера.
  • Позволяет тестировать асинхронные вызовы. Silverlight работает асинхронно, это означает что все вызовы, например к сервисам, будут происходить асинхронно, а это означает что это тоже необходимо протестировать. Поэтому MS Silverlight Unit Test Framework предоставляет простой способ написания асинхронных тестов. Необходимо просто наследовать класс с асинхронными тестами от класса SilverlightTest, затем применить соответствующие атрибуты [TestMethod, Asynchronous], указать таймаут, если необходимо, с помощью атрибута [Timeout(5000)] и далее управлять выполнением теста с помощью соответствующих методов EnqueueCallback(), EnqueueConditional(), EnqueueTestComplete(), EnqueueDelay(), TestComplete().
  • Позволяет протестировать приложение в различных браузерах.

Agile development

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

Начнем с того что же такое «Agile development»? Что же означает это модное выражение?

Многие программисты, работающие в реальных условиях бизнеса и разрабатывающие бизнес-приложения, знают, что программирование задача не из легких. Очень часто заказчик не может четко и понятно сформулировать свои требования. А многие, казалось бы, уже сформулированные требования противоречат друг другу. Да и правила бизнеса могут меняться в процессе разработки. Зачастую не разбираясь во всех деталях предметной области, программист видит стоящую перед ним проблему по-своему, и соответственно решает её, как он считает, правильным путем. Однако получая релиз программы, заказчик понимает, что программа делает не то, что хотелось бы. И непонимание между клиентом и заказчиком в итоге выливается в ненужный программный продукт. Тем самым, мы можем сделать вывод о том, что программа - это не монолитная и неизменная структура, мы не можем заранее предсказать все требования к конечному продукту, а значит, программисты должны своевременно реагировать на изменение требований. А для этого разрабатываемый программный продукт должен быть достаточно гибок для изменения направления развития и податлив для модификации в целом. Именно на это и нацелены практики гибкой разработки приложений (Agile development).

Существует множество методологий гибкой разработки, подробнее расскажу о тех, с которыми познакомились мы в летней школе Intel, а именно это практики экстремального программирования (XP) и методология Scrum. Практики гибкой разработки:

  • Сидеть вместе - Sit together. Это простое правило способствует общению в команде, что является немаловажным фактором успеха команды в целом.
  • Информативное рабочее пространство - Informative workspace. Различного рода информационные доски помогают быстро и четко видеть весь проект в целом, а также, на каком этапе идет разработка.
  • Парное программирование - Pair programming. Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы (driver), другой (observer) наблюдает, но это не значит, что отдыхает. Он также активно участвует в разработке - следит за ошибками, одновременно делает code review и участвует в решении поставленных задач. В течение работы пары меняются, что усиливает взаимодействие внутри команды, и обеспечивает коллективное владение кодом - все это одни из факторов успеха команды, а соответственно и всего проекта.
  • Полная команда - Whole team. В терминах XP «заказчик» это не тот, кто платит за проект, а тот, кто действительно будет работать с создаваемым программным продуктом. Поэтому заказчик - это один из участников команды, он должен быть всегда доступен для ответа на возникающие у разработчиков вопросы.
  • Энергичная работа - Energized work. Вся команда работает энергично и не больше 40 часов в неделю.
  • Разработка через тестирование - Test Driven Development. Основное правило - пишем тесты до кода, что в результате приводит к созданию компактных и легковесных классов с требуемой функциональностью. Помимо этого, TDD позволяет быстро обнаруживать слабые места в дизайне и безопасно делать рефакторинг кода (code refactoring).

Это основные практики, которые мы старались применять во время стажировки. Хотя команда у нас была небольшая, но, тем не менее, применяя практики XP и Scrum, мы сразу заметили, как повысилась эффективность нашей работы, и наши труды стали давать ощутимый результат. Весь процесс разработки разбивался на небольшие недельные итерации (sprints). Нашим «заказчиком» была группа разработчиков SMG, которой мы каждую неделю рассказывали о наших успехах и показывали достигнутые результаты. Они в свою очередь высказывали нам свои замечания и пожелания. После этого мы планировали работу на следующую итерацию: определяли список user stories, распределяли их по приоритетам, делили их на задачи (tasks) и в конечном итоге получали sprint backlog и так нами любимый burn down chart, который мы непременно хотели «сжечь» как можно быстрее. Казалось бы, ничего сложного, но насколько эти вещи мотивировали нас к работе и повышали нашу производительность. Вот в таких необыкновенно новых, но в то же время интересных условиях мы и работали.

Заключение

Тем самым, за время прохождения стажировки были решены все поставленные задачи, а именно:

  • Изучен шаблон проектирования бизнес приложений - Model View Presenter, а также подход к проектированию Domain Driven Design и показана возможность их применения к технологии Silverlight.
  • Освоена практика разработки приложений через тестирование (TDD) и продемонстрирована возможность её применения при разработке Silverlight приложений. При этом были изучены платформы для тестирования MS Unit Test Framework и MS Silverlight Unit Test Framework и даны рекомендации по их применению.
  • Спроектирован и разработан прототип приложения для сравнения показателей качества исходного кода программных решений SMG, а также для просмотра информации по проектам и их разработчикам.
  • И, конечно же, был получен неоценимый опыт в применение гибких методов разработки, в частности XP и Scrum.

В заключение хочу выразить благодарность организаторам Летней Школы за подаренную возможность обучения и приобретения новых знаний с помощью компании Intel. Отдельно хочется выразить огромную благодарность Евгению Сорокину, Антону Бевзюку и всей команде разработчиков SMG за те знания и опыт, которыми они с нами так просто и открыто делились. Спасибо. Все знания, полученные в Летней Школе, уже находят применение в моей трудовой деятельности.

Об авторе

Федореева Мария Александровна. В 2009 году закончила Ивановский Государственный Энергетический Университет по специальности Компьютерное обеспечение вычислительной техники и автоматизированных систем. Летом 2009 года принимала участие в Летней молодежной школе-стажировке Intel в городе Нижний Новгород. Сфера профессиональных интересов: интеллектуальный анализ данных, OLAP технологии, разработка бизнес-приложений на основе SOA технологий, web-технологии, мобильные технологии.