Файл: Разработка сайта страховой компании «Согласие».pdf

Современные веб-приложения обслуживают не только HTML-разметку; часто они должны также предоставлять данные JSON или XML различным клиентским технологиям, включая AJAX, Silverlight и собственные приложения смартфонов. При использовании REST это происходит естественным образом, устраняя историческое различие между веб-службами и веб-приложениями, но требует определенного подхода к обработке HTTP и URL, который было непросто поддерживать с помощью ASP.NET Web Forms [2, c 25].

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

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

Очевидными примерами являются разработка через тестирование (test-driven development – TDD) и ее новейшее воплощение – разработка через тестирование поведения (behavior-driven development – BDD). Идея состоит в проектировании программного обеспечения, сначала описывая примеры желаемого поведения (которые известны, как тесты или спецификации), чтобы в любой момент можно было проверить стабильность приложения и его корректность, выполнив набор спецификаций применительно к текущей реализации. Недостатка в инструментах.NET поддерживающих TDD/BDD, нет, но они не слишком хорошо работают с Web Forms [3, c. 27].

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

Инструменты автоматизации пользовательского интерфейса позволяют имитировать серии взаимодействий пользователя с готовым действующим экземпляром приложения. Теоретически их можно попользовать в Web Forms, но все рушится, стоит только слегка изменить компоновку страницы. Без принятия специальных мер, платформа Web Forms создает совершенно другие структуры HTML и идентификаторы элементов, делая существующую среду тестирования бесполезной.

Сообщество независимых поставщиков программного обеспечения (independent software vendor – ISV) вместе с сообществом открытого кода разработали множество высококачественных платформ для модульного тестирования (NUnit и MBUnit), имитации (Rhino Mocks и Moq), контейнеров инверсии управления (Ninject), серверов непрерывной интеграции (Cruise Control и TfeamCity), средств объектно-реляционного отображения (NHibemate и Subsonic). Сторонники этих инструментов и методов нашли общий язык, публикуя материалы и организуя конференции под общей маркой ASP.NET. Вследствие своего монолитного проектного решения традиционная технология ASP.NET Web Forms не слишком подходит для таких инструментов и приемов, поэтому удостаивается не слишком большого почтения со стороны этой шумной группы экспертов и интеллектуальных лидеров отрасли [4, c. 28].

Ещё 2004 году платформа Ruby on Ralls была тихим, незаметным продуктом с открытым исходным кодом от неизвестного игрока. Но неожиданно она добилась популярности, изменив правила веб-разработки. Это было связано не с тем, что Ruby on Rails представила революционную технологию, а с тем, что она собрала существующие ингредиенты и смешала их таким чудесным, волшебным, великолепным способом, что смогла пристыдить существующие платформы.

Ruby on Rails (или просто Rails, как ее обычно называют) заключала в себя архитектуру МVС. Применение архитектуры MVC и работа в гармонии с протоколом HTTP, а не в противовес ему, внедрение соглашений вместо обязательного конфигурирования и интеграция инструмента объектно-реляционного отображения (object-relational mapping – ORM) в ядро позволило приложениям Rails без особых усилий завоевать относительно высокую популярность. Это было похоже на открытие того, какой должна быть веб-разработка: все осознали, что все эти годы, по сути, сражались со своими инструментами, и вот, наконец, война окончена.

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

Благодаря Rails, вскоре появилось множество веб-разработчиков, использующих Ruby в качестве своего основного языка программирования. Но в столь новаторском сообществе появление альтернатив Rails было лишь вопросом времени. Наиболее известная из них, Sinatra, была представлена в 2007 году Sinatra отбрасывает почти всю стандартную инфраструктуру в стиле Rails (маршрутизацию, контроллеры, представления) и просто отображает шаблоны URL на блоки кода Ruby. Посетитель запрашивает URL, что ведет к выполнению блока кода Ruby, и данные отправляются обратно браузеру – и это все. Такой вид веб-разработки невероятно прост, однако он нашел применение в двух основных областях. Во-первых, для тех, кто строит веб-службы, поддерживающие REST, он позволяет решить задачу быстро. Во-вторых, поскольку платформа Sinatra может быть соединена с широким множеством шаблонов HTML с открытым исходным кодом и технологий ORM, она часто используется в качестве основания для сборки нестандартных веб-платформ, способных удовлетворить архитектурные потребности любого проекта.

Тем не менее, платформе Sinatra еще только предстоит отвоевать значительную часть рынка у полноценных MVC-платформ, подобных Rails (или ASP.NET MVC).

Еще одна важная тенденция – переход к использованию JavaScript в качестве основного языка программирования. AJAX первым продемонстрировал важность JavaScript, jQuery показал, что этот язык может быть мощным и изящным; а JavaScript-механизм с открытым исходным кодом V8 от Google показал, что он может быть невероятно быстрым. В настоящее время JavaScript становится серьезным языком программирования серверной стороны. Он служит языком хранения и запросов данных для нескольких не реляционных баз данных, включая Couch DB и Mongo, и используется в качестве универсального языка в серверных платформах, таких как Node.js.

Платформа Node.js существует с 2009 года, и она очень быстро завоевала широкое признание. С точки зрения архитектуры она подобна Sinatra тем, что не применяет подход MVC. Скорее она представляет собой способ связывания HTTP-запросов с кодом. В ней применены следующие основные новшества.

Использование JavaScript. Разработчикам нужно иметь дело только с единственным языком – в клиентском коде, внутри логики серверной стороны, в логике запроса данных через Couch DB [1, c. 55].

API – интерфейс Node.js не предоставляет никакого способа блокировки потока во время ожидания ввода – вывода или любой другой операции. Весь ввод-вывод реализуется за счет старта операции, а затем позднее приема обратного вызова после завершения ввода-вывода. Это означает, что Node.js чрезвычайно эффективно использует системные ресурсы и может обрабатывать десятки тысяч одновременных запросов на один ЦП (как правило, возможности альтернативных платформ ограничиваются приблизительно 100 одновременными запросами на один ЦП).

Как и Sinatra, Node.js – технология для определенного круга пользователей. Большинство компаний, создающих реальные приложения в ограниченные временные сроки, остро нуждается во всей инфраструктуре полномасштабных платформ, таких как Ruby on Rails и ASP.NET MVC. Node.js упоминается здесь только для того, чтобы часть проектного решения ASP.NET MVC можно было рассмотреть в контексте отраслевых тенденций. Например, ASP.NET MVC включает в себя асинхронные контроллеры. Это служит способом обработки запросов HTTP с применением неблокирующего ввода-вывода и масштабирования для обработки большего количества запросов на один ЦП [3, c. 824].

Обоснование выбора средств разработки приложения

Для разработки программного продукта была выбрана технология ASP.NET MVC 3 и язык C#, являющийся самым популярным языком для написания бизнес логики на платформе.NET, основные преимущества технологии ASP.NET MVC 3:

– Использование встроенного архитектурного шаблона MVC.

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

– Жесткий контроль над HTML и HTTP. В платформе ASP.NET MVC учтена важность генерации ясного и соответствующего стандартам кода разметки. Ее встроенные вспомогательные методы HTML создают соответствующий стандартам вывод, но в ней реализовано и гораздо более значимое философское изменение по сравнению с Web Forms. Вместо громадного объема трудно поддающегося управлению HTML-кода, платформа MVC стимулирует создание простых и элегантных, стилизованных с помощью CSS компонентов.

– Тестируемость. Естественное разнесение различных задач приложения по разным, независимым друг от друга частям программного обеспечения, поддерживаемое архитектурой MVC. позволяет изначально строить легко сопровождаемые и тестируемые приложения. Однако проектировщики ASP.NET MVC на этом не остановились. Для каждого фрагмента компонентно-ориентированного дизайна платформы они обеспечили структурированность, необходимую для выполнения требований модульного тестирования и средств макетирования.

В качестве IDE была выбрана Visual Studio 2010 – это интегрированная среда разработки Microsoft (IDE), являющейся самой функциональной IDE для разработки на платформе.NET.

Для модульного тестирования была выбрана встроенная поддержка в Visual Studio 2010 так как в настоящий момент функциональность встроенной поддержки ничуть не хуже чем у конкурентов, а тесная интеграция с IDE ставит её на первое место.

В качестве DI контейнера был выбран Ninject. Он прост, изящен и легок в использовании. Существуют более сложные альтернативы, но Ninject функционирует при минимальном конфигурировании.

Для создания реализаций интерфейсов, предназначенных для использования в модульных тестах был выбран Moq, представляющий собой комплект инструментов имитации.

Для хранения данных был выбрана СУБД SQL Server 2008 и ORM Entitty Framework от Microsoft. Так как оба продукта от Microsoft у них есть наиболее тесная интеграция с другими продуктами.

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

На рисунке 5 представим общую укрупненную блок-схему всего Web-приложения.

Рисунок 5 - Блок-схема всего Web-приложения

В качестве дальнейшего рассмотрения алгоритмов курсовой работы, представим блок-схемы алгоритма авторизации пользователя, это будет рисунок 6 и на рисунке 7 представим алгоритм вывода услуг и их описания.

Рисунок 6 - Блок-схема авторизации пользователя

Рисунок 7 - Блок-схема алгоритма вывода услуг и их описания

Данные алгоритмы широко применяются и в других местах программного комплекса. Только зодейвуются другие объекты. Например: регистрация менеджера и добавление услуги.

Схема базы данных.

Для реализации базы данных проекта «Сайта страховой компании» необходимы следующие таблицы базы данных. Таблицы представим в таблице 1.

Таблица 1 - Сущности БД и их назначение

Физическую модель БД представим на рисунке 8.