SILVERLIGHT: TDD+DDD+MVP

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

07.10.2009 14:00


Аннотация

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

  • Применение шаблонов проектирования бизнес-приложений;
  • Освоение практики TDD;
  • Обучение практикам гибкой разработки;
  • Разработка прототипа Silverlight-приложения.

В результате исследования было разработано приложение на Silverlight с использованием TDD, MVP, DDD.

Введение

В прошлом году я впервые услышал о технологии Silverlight и о возможности пройти стажировку в компании «Интел». В этом году мне удалось, что называется, потрогать руками этот самый Silverlight и почувствовать себя частью компании «Интел».

Передо мной как участником Летней Школы была поставлена цель – изучить технологию Silverlight на предмет применимости в разработке бизнес-приложений. Цель, казалось бы, не бог весть какая, но на поверку все оказалось крайне увлекательно. Изучение новой технологии само по себе представляет мало интереса, как многие, я думаю, со мной согласятся. Изученное необходимо применять на практике и применять так, чтобы была польза, чтобы что-то оставалось после этого обучения. Для меня Silverlight являлся заманчивым «черным ящиком», и вот почему. Вообще говоря, я люблю посидеть над кодом, всласть так попрограммировать. Но для меня также немаловажен результат работы. Когда дело касается web-технологий, встает вопрос о качественном дизайне и производительности, о пользовательских ощущениях и общем впечатлении о продукте в условиях ограниченных возможностей браузера. Всегда хочется, чтобы софт выглядел профессионально и красиво, причем как с точки зрения разработчика, так и пользователя как конечного потребителя. Поэтому, когда я увидел широко рекламируемые возможности Silverlight, у меня возникло стойкое желание стать к ним немного ближе.

Итак, есть цель, осталось разобраться с задачами. А задач было несколько, приведу их со своими комментариями:

  • Исследовать шаблоны проектирования бизнес-приложений. Каюсь, до Летней Школы знания мои в этой области были скудны и ценности особой не представляли.
  • Освоить практику TDD. Натыкаясь в интернете на статьи про Test Driven Development, меня охватывало чувство легкого непонимания, я совершенно не понимал, зачем это надо.
  • Научится практикам гибкой разработки. Полный ноль.
  • Разработать прототип Silverlight-приложения. То, что хотелось, но не моглось.
  • Выработать практики и рекомендации по разработке приложений на Silverlight. Делать добро людям всегда приятно.

В первый же день Летней Школы эти задачи были передо мной поставлены. Есть цель, есть задачи – пора, засучив рукава, приступать к достижениям и решениям.

Основная часть

Для начала хочу упомянуть, что над проектом работали двое – я и Мария Федореева. Почему – увидите дальше.

Гибкая разработка и TDD

В первый же день наш менеджер, Евгений Сорокин, показал нам магию, особую магию сектантов, исповедующих методику гибкой разработки и разработку через тестирование. А все было довольно прозаично – он взял и написал за полчаса-час (сейчас уже не помню точно) Приложение. Почему с большой буквы? Да потому, что архитектура по своей четкости и красоте превосходила все те приложения, которые я когда-либо писал или видел раньше. Время, затраченное на реализацию, было минимальным. Покрытие кода тестами – максимальное. Расширяемость и масштабируемость – выше всяческих похвал. Меня охватил щенячий восторг и захотелось научиться делать также. Итак, практики гибкой разработки:

  • Сидим вместе, всей командой. Желательно в одной комнате без перегородок;
  • Используем всяческие информационные доски;
  • Работаем всей командой, энергично, по 40 часов в неделю;
  • Пишем код парами;
  • Используем TDD;
  • Проектируем пошагово;
  • Используем интеграционное тестирование;
  • Выпускаем часто релизы;
  • Используем практики планирования;
  • Тесно работаем с заказчиком.

Данный список, безусловно, не является полным, пришлось немного укоротить, чтобы уместиться в формат статьи. Но, тем не менее, основное представление получить можно. Впрочем, я думаю, что неплохо было бы рассказать вкратце о TDD (Test Driven Development):

TDD – это:

  • Тесты до кода;
  • Методология разработки;
  • Практика дизайна.

Цели TDD:

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

Цикл работы по TDD (Red-Green-Refactor):

  • Начало;
  • Подумай, напиши тест;
  • Скомпилируй;
  • Исправь ошибки;
  • Запусти тесты и убедись, что они упали;
  • Напиши код;
  • Запусти тесты, убедись, что они прошли;
  • Устрой рефакторинг кода;
  • Если нужно продолжать развивать код, возвращайся на пункт 2.

Вот примерно по такой схеме мы и работали. У нас был «заказчик», который рассказывал о своих желаниях, и которому мы каждую неделю презентовали очередной релиз, у нас был Scrum-мастер – наш непревзойденный менеджер, который наводил нас на путь истинный, используя ухищрения типа ретроспективы, мы работали над кодом в паре, используя TDD, – в общем, в нашей команде на ноги была поставлена гибкая методика разработки.

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

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

Наш набор юного программиста включал в себя Visual Studio 2008 и ReSharper 4.5. В начале июля вышла третья версия Silverlight, которую и пустили в дело. Порывшись немного в себе, обнаружили скромный дизайнерский талант, поэтому установили еще и Blend 3. Подробно о том, какие инструменты нужны, и где их взять, описано здесь.

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

Архитектура

Решив, что приложение у нас будет построено не абы как, сделали архитектуру на Model-View-Presenter. Для того чтобы статья не превысила размера трех пьес Шекспира, приведу описание архитектуры в виде картинок.

Физическая структура приложения

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

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

Распределение классов

Domain
Итак, определим объекты, которые будут храниться у нас в домене (Domain). Это классы, описывающие различные сущности реального мира, например, разработчика (класс Developer). Также, в домене у нас будут находиться интерфейсы фасада и адаптеров.

Presentation
В слое Presentation у нас будут храниться интерфейсы представлений (View), сущности презентеров (Presenter Entities) и непосредственно сами презентеры. Сущность презентера – это «голое» представление объектов классов из слоя Domain, т.е. ровно то, что будет отображать UI, ничего более. Например, у класса Developer есть свойство id, которое слою представления знать ни к чему. Поэтому у класса PEDeveloper этого свойства нет.

ClientInfrastructure
В слое ClientInfrastructure у нас определены классы, ответственные за коммуникацию. Есть фасад (паттерн Gang of Four, да) и набор классов-адаптеров. Например, для замученного нами класса Developer есть класс DeveloperAdapter, основная задача которого – на команду от класса DeveloperPresenter «Сохрани мне этих девелоперов» отвечать «Да, сейчас сохраню» и, естественно, непосредственно сохранять.

UI
Здесь все просто. Есть несколько страниц, на которых надо красиво отобразить данные, полученные от слоя Presentation.

С клиентской частью мы разобрались, теперь пора браться за серверную, т.е. надо думать, как данные получать и сохранять. Решили, что будем использовать WCF-сервис, и после этого решения наши вечера в Нижнем Новгороде перестали быть томными. Какие проблемы возникли:

  • Как использовать доменные объекты на сервере и на клиенте?
  • Как передавать доменные объекты с сервера на клиент и обратно?

Дело вот в чем. Silverlight – это ведь, по сути, сильно урезанный полноценный .NET Framework. И поэтому вполне закономерно, что мы не можем использовать сборки Silverlight в проектах .NET, и наоборот. Более того, если мы будем использовать WCF-сервис, то он будет возвращать нам на клиенте прокси-объекты, которые нам использовать не хочется. Просмотрев более 9000 страниц в интернете, мы нашли решение.

  1. Создаем слой Domain полностью на Silverlight. Для этого создаем в Visual Studio проект Silverlight Class Library – назовем его Domain.Silverlight, default namespace которого зададим равным “Domain”;
  2. Создаем в Visual Studio обычный проект Class Library, назовем его Domain.Web и его default namespace установим также равным “Domain”;
  3. В проект Domain.Web добавляем ссылки на файлы из проекта Domain.Silverlight.

Таким образом, у нас есть две сборки, одна обычная, вторая для Silverlight. Пространство имен у них одинаковое и классы – тоже. Теперь что нам остается сделать:

  • Создать WCF-сервис в нашем web-проекте (Infrastructure);
  • Добавить ссылку на файл *.ClientConfig в проект с UI.

И все, проблема с разными объектами решена. Теперь надо эти объекты как-то передавать, и сериализация – это ответ на вопрос. Но здесь мы немного огребли горя – Silverlight ведь урезан, и выбор способов сериализации невелик. Решение: единственный доступный на Silverlight сериализатор – это DataContractSerializer, поэтому выбрали его. Берем класс Developer и помечаем его атрибутом [DataContract]. Каждое свойство класса, которое нужно будет передавать, помечаем атрибутом [DataMember]. Объекты сериализуем в строку, которой и кидаемся от сервера к клиенту и наоборот. В итоге ход работы у нас такой:

  • Данные из базы данных достаем через ORM LINQ to SQL Classes;
  • Если нужно, то с помощью LINQ формируем списки объектов, например, список разработчиков;
  • Отправляем данные сериализатору, который преобразует их в строку;
  • Отправляем строку через WCF-сервис клиенту, который, получив данные, десериализовывает все объекты.

Теперь, вроде бы, все хорошо. За еще одним НО: если мы хотим передавать изображения (массив байт), то ничего не передается, и при этом еще выдаются непонятные ошибки. А причина, как оказалось, в общем-то проста как три рубля – объем данных получался больше, чем было прописано в файле конфигурации сервиса (мы использовали basicHttpBinding). Поэтому после правки параметров все заработало. При отладке сервиса нам очень помогла утилита wcftestclient.exe, которая запускается из командной строки Visual Studio.

Стоит наверное упомянуть, что все вызовы к сервисам у Silverlight асинхронные. А это тоже надо тестировать. Вообще, тестирование поначалу вызвало много вопросов. Какие рекомендации можно дать: если используете MS Unit Test Framework (встроенный в VS), то отлаживать сборки Silverlight можно. Естественно, не без ухищрений – нужно использовать только системные сборки Silverlight. Например, если в сборке А используется LINQ, то в тест-проект нужно добавить ссылку на сборку Silverlight System.Core, иначе будут валиться ошибки типа «не могу найти такую-то сборку», причем вроде бы непонятно, почему.

Есть еще одна возможность по тестированию – MS Silverlight Unit Test Framework. Проведя исследование, мы решили использовать ее для следующих целей:

  • Тестирование асинхронных вызовов. Очень удобно в написании интеграционных тестов. Если кратко, то все операции ставятся в очередь, и переход от операции к операции осуществляется только после завершения предыдущей, при этом можно задать ограничение по времени на выполнение одного теста.
  • Тестирование анимации, пользовательских компонентов, интерфейса в различных браузерах. Большой минус – все действия нужно жестко прописать в программе. Честно говоря, лучше использовать сторонние продукты, например бесплатный WebAii Testing Framework от Telerik.

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

Когда сервис был написан, захотелось развернуть его на IIS. И тут, как вы понимаете, у нас тоже возникло непонимание. Ничего не работало, вообще. Но мы молодцы! Итак, как развернуть сервис и приложение на IIS:

  • WCF-сервис
    1. Построить сервис;
    2. Настроить кросс-доменную политику;
    3. Запустить утилиту настройки IIS – «ServiceModelReg.exe –i»;
    4. Настроить логин и пароль для СУБД
  • Web-сайт
    1. Если используется IIS 7, то достаточно просто опубликовать сайт;
    2. Если используется IIS 6, то нужно добавить типы MIME:
      • «.xap     application/x-silverlight-app»
      • «.xaml    application/xaml+xml»
      • «.xbap    application/x-ms-xbap»

И, вот, все работает.

Напоследок расскажу о двух вкусных вещах в Silverlight 3. Это Navigation Framework и Out-Of-Browser Feature.

Navigation Framework – это, если проводить аналогии, своего рода Master Pages в ASP .NET. То есть, у нас теперь некая главная страница с фреймом. Внутри этого фрейма можно располагать другие страницы. Если раньше форма на Silverlight была пользовательским компонентом (User Control), то теперь форма является страницей (Page). И эти страницы можно свободно располагать внутри фрейма главной страницы, причем есть интеграция с историей браузера – например, при нажатии на кнопку браузера «Назад» мы возвращаемся не к сайту, который посетили до нашего Silverlight-приложения, а к предыдущей странице нашего приложения. Если таковые имеются, естественно.

Любопытная возможность третьей версии Silverlight – это возможность запускать приложения, на нем написанные, вне браузера. Причем все по-честному, перед пользователем появляется стандартное окно приложения Windows. Все, что нужно для этого сделать – отметить галочку в свойстве Silverlight-проекта «Enable running application out of the browser» и настроить несколько свойств типа заголовка окна. И все! Пользователь затем сможет, щелкнув правой кнопкой по приложению в браузере, вызвать диалог установки. Либо можно установить приложение по нажатию кнопки, выполнив определенный код. Главное – чтобы действие было инициировано именно пользователем, и притом диалог установки приложения все равно появится.

И в заключение скажу несколько слов о Blend 3. Вообще этот инструмент рассчитан на дизайнеров. Так нам как бы намекает его необычный интерфейс. Но пользоваться им оказалось довольно просто. Достаточно было просмотреть обучающее видео и прочитать несколько статей. С помощью Blend 3 можно легко заменить вид стандартной кнопки, разобрав ее на «запчасти» и заменив шаблоны вида и поведения.

Заключение

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

Наши исследования показали, что новая технология от Microsoft имеет некоторые ограничения, которые, впрочем, вполне преодолимы. Также, мы выяснили, что можно вполне успешно применять patterns&practices, принятые разработчиками во всем мире.

За время Летней школы поставленные цели были достигнуты, возникшие проблемы – успешно решены. Надеюсь, эта статья внесет свою лепту в разработку ваших приложений на Silverlight.

Об авторе

Кречун Евгений Павлович, выпускник Вятского государственного гуманитарного университета (г. Киров), окончил в этом году факультет Информатики. В сферу профессиональных интересов входят такие области, как искусственный интеллект, автоматическая обработка текста, пользовательские интерфейсы, олимпиадное программирование, разработка сложных информационных систем. На конкурсе Imagine Cup в 2007г. занял третье место в «Project Hoshimi». Участник ACM 2007г.

Список использованных материалов и литературы

  1. Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”
  2. Jimmy Nilsson, “Applying Domain-Driven Design and Patterns”
  3. www.agiledev.ru
  4. Кент Бек, «Экстремальное программирование»
  5. Роберт Мартин, «Быстрая разработка программ»
  6. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес, «Приемы объектно-ориентированного проектирования»