CC BY
164
УДК 004.415.2(06)
ИСПОЛЬЗОВАНИЕ ПАТТЕРНА ПРОЕКТИРОВАНИЯ MODEL-VIEW-CONTROLLER
ПРИ РАЗРАБОТКЕ WEB-ПРИЛОЖЕНИЙ
Беликова Наталья Валентиновна, к.т.н., доцент, Шахтинский институт (филиал) Южно-Российского государственного технического университета (Новочеркасского политехнического института), Россия, Шахты,
Галич Марк Геннадьевич, студент, Шахтинский институт (филиал) Южно-Российского государственного технического университета (Новочеркасского политехнического института), Россия, Шахты, [email protected]
Паттерны проектирования - это шаблоны, адаптированные под решение наиболее общих задач, основное предназначение которых - описание взаимодействия объектов в приложении. Паттерн не является законченным образцом, и не может быть прямо преобразован в код; это лишь вспомогательный каркас для задачи, который может существенно упростить разработку приложения. Объектно-ориентированные шаблоны показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться [1].
Большинство разработчиков в наше время применяют объектно-ориентированный подход в программировании при работе над крупными проектами, или хотя бы знакомы с его основной концепцией. Трудно, а порой даже не возможно, начинать серьезную работу с нуля, не используя наработок в коде или хотя бы в проектировании. В связи с этим, у программистов появляется потребность выделять для себя ключевые моменты из каждого проекта и с каждым разом, абстрагируясь от каких-то конкретных задач, строить каркас для будущих разработок. Такой подход удобен при индивидуальной работе над проектом. Если же разработку ведёт команда, то работу будет задерживать необходимость вникать в выработанный годами подход. Остаётся или тратить огромное количество времени на изобретение очередного велосипеда, или же начать использовать различные паттерны проектирования.
Паттерн проектирования Model-View-Controller (Модель-Представление-Контроллер) лег в основу архитектурного решения первой среды программирования с графическим интерфейсом пользователя - Smalltalk-80. Впервые MVC описал еще в 1978 году норвежец Трюгве Ринскауг, работавший некоторое время в лаборатории Xerox PARC [3]. Реализацию шаблона в Smalltalk-80 описал несколько позже Стив Бурбек [4].
100
Архитектура Model-View-Controller позволяет разделить модель данных, пользовательский интерфейс и управляющую логику на три отдельные составляющих (Рис. 1). Причем разделить так, что изменение одного компонента не повлияет на работу остальных. Использовать эту архитектуру особенно удобно при командной работе над большими проектами. Например, при разработке web-приложения, можно отделить разработку части сайта, отвечающей за обработку данных, абсолютно не беспокоясь о том, как эти данные будут представлены, т.к. над интерфейсом приложения могут абсолютно независимо работать верстальщики и дизайнеры. Что же касается программистов, то они также могут разделять свою работу - например, часть разработчиков может сосредоточиться на разработке логики программы, а другая - на проектировании структуры базы данных. Из описанных выше примеров видно, что при использовании MVC становится возможным распределить работу команды, тем самым повысив общую производительность.
MVC состоит из следующих сущностей [2]:
• Модель данных (Model) в целом понимается как компонент администрирования данных. В большинстве случаев это общение с базами данных - выборка определённых данных, добавление новых и изменение существующих. Модель не знает, в каком виде надо представлять запрашиваемые у неё данные пользователю, она лишь совершает операции с «сырыми» данными. Она должна иметь стандартизированный универсальный интерфейс, чтобы одну модель могло использовать любое количество других подсистем любое количество раз.
• Вид (View) описывает формат вывода данных пользователю, то есть визуальное представление данных, взятых из Модели. Он получает на входе набор сырых данных, которые необходимо передать пользователю, форматирует их в соответствии с требованиями пользователя (на примере веб-разработок - одна и та же страница может быть представлена как в виде HTML-документа, так и в XML, JSON и т.д.). Главное удобство системы видов состоит в том, что для каждого конкретного случая представления данных не надо описывать шаблон целиком, можно скомпоновать его из нескольких стандартных блоков и одного, уникального для этого случая. Это избавляет от проблем с внесением изменений в шаблон, когда требуется изменить, допустим, заголовок сайта на всех его страницах (если все страницы сайта используют один Вид заголовка, достаточно изменить лишь его, а не менять вручную шаблон каждой страницы).
• Контроллер (Controller) осуществляет управление всеми процессами приложения. Он обрабатывает внешние запросы и выполняет содержащиеся в этих запросах требования, раздавая соответствующие указания Моделям, и передает полученные от Моделей данные соответствующим ситуации Видам для корректного вывода нужной информации.
В целом, работу MVC можно представить так:
• команда (уведомление о нажатии кнопки, запроса адреса сайта и т. д.) передается Контроллеру;
• Контроллер, исходя из полученных данных, определяет и вызывает Модель;
• Модель, на основе заложенной в нее бизнес-логики, формирует набор данных;
• Контролер выбирает Представление и связывает его с данными (Моделью);
• Представление отображает данные пользователю.
К основным минусам паттерна MVC можно отнести:
• Увеличение объема кода по сравнению с программированием без применения каких-либо паттернов;
• Необходимость соблюдения заранее заданного интерфейса;
• Для поддержки разработки требуются более квалифицированные специалисты.
К главным плюсам отнесём следующее:
• Более гибкий код;
• Возможность повторного использования каждой из трёх составных частей MVC;
101
• Безболезненная замена и изменение каждого из элементов системы (другие алгоритмы расчета, способы хранения данных, визуальные представления и т.д.);
• Скорость разработки;
• Легкость поддержки кода.
В современном мире нет ничего статичного, и, пожалуй, в наибольшей степени это касается программного обеспечения. Объемы и сложность современных приложений (как среди «настольного» ПО, так и среди серверного и веб-сервисов) растут с пугающей скоростью. Любое приложение профессионального уровня представляет собой сложную, комплексную систему, которую невозможно воплотить в жизнь, не введя в процесс разработки определённый уровень абстракции. MVC позволяет легко превратить тысячи строк кода в стройную и логично устроенную систему, которую легко можно объять взглядом одного разработчика, и лишает разработку и последующее развитие кода множества проблем по интеграции нового кода со старым.
В настоящее время паттерн Model-View-Controller широко используется в php-фреймворках (Symfony, CodeIgniter, Kohana, Yii и тд), а также в ASP.NET, Django, Ruby On Rails и множестве других разработок. Сегодня MVC можно назвать стандартом де-факто в веб-разработке, как, например, использование реляционных баз данных - они подходят не для всех задач, но для большинства; а в случаях, когда они не подходят, использование нестандартных решений порой вызывает больше проблем (например, с обучением специалистов), нежели не совсем подходящие, но более привычные средства.
Литература
1. http://ru.wikipedia.org/wiki/Шаблон_проектирования
2. http://msdn.microsoft.com/en-us/library/ff649643.aspx
3. http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
4. http://www.math.rsu.ru/smalltalk/gui/mvc-rus.pdf
УДК 004.75
РАСПРЕДЕЛЕННЫЙ ТЕСТИРУЮЩИЙ КЛИЕНТ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ПРОВЕДЕНИЯ СОРЕВНОВАНИЙ ПО ПРОГРАММИРОВАНИЮ1
Визовитин Николай Валерьевич, магистрант, Новосибирский Государственный Университет,
Россия, Новосибирск, vizovitin@gmail. com
Введение
Многие современные соревнования по программированию (например, ACM ICPC) для оценки решений участников используют ту или иную специализированную тестирующую систему. Как правило, такие системы позволяют исполнять программу, написанную участником, в автоматическом режиме на заранее определенном наборе сценариев. В простейшем случае программа запускается на серии предварительно подготовленных тестов. Кроме того, осуществляется контроль над используемыми программой ресурсами, а также обеспечивается изоляция и равноправие при исполнении различных решений. Примером таких систем могут служить ejudge, PCMS2, PC2, NSUts [1].
Большинство автоматических систем тестирования имеют клиент-серверную архитектуру. В рамках такого разделения сервер отвечает за взаимодействие с пользователями и принятие решений участников на проверку. Но непосредственно проверка корректности решений осуществляется на нескольких тестирующих клиентах. Участники не имеют прямого доступа к тестирующим клиентам. Как правило, тестирующие клиенты запускаются на отдельных физических машинах, равно как и сервер. Основная причина
1 Работа выполнена при проведении НИР в рамках реализации ФЦП «Научные и научно-педагогические кадры инновационной России» на 2009 - 2013 годы, ГК № П262 от 23.07.2009.
102
