Добро пожаловатьмобильная версиявход
В Мир Информационных Технологий
ЛЕНТА
ЧЗВ (FAQ)
КАРТИНКИ
ОБ АВТОРЕ
КУЗНИЦА
веб
игры
наука
остальное
путешествия
разработка
софт
технологии
устройства
Model View Controller (MVC) опыт использования, выводы
2015-01-29 18:53 | | комментарии - 0разработка
Недавно закончил свой первый проект, реализованный согласно концепции Model-View-Controller (MVC, хотя с технической точки зрения, правильнее было бы CMV). В статье предлагаю читателю познакомиться с моими личными впечатлениями от концепции.

Примечание
Все написанное в статье – это мое личное мнение. Вы, как читатель, не обязаны с ним соглашаться.
Цель статьи – ознакомить читателя с еще одним мнением, относительно распространенной концепции.

Мой путь к MVC
Некоторое время назад, мной было принято решение сделать свой блог. Повозившись какое-то время с WordPress пришел к выводу, что "там рыбы нет" (и сегодня, глядя на статистику запросов к сайту считаю, что отказ от WordPress было правильным решением). В общем, проанализировав совокупность внешних факторов (мои знания, необходимое время на разработку, доп. затраты на обслуживание и т. д.) решил все разработать самостоятельно, с нуля. И т. к. теперь у меня руки были развязаны (в выборе механизмов программной организации), решил опробовать "на себе" широко разрекламированную концепцию MVC (в предыдущих проектах я использовал модульный подход).

Мое понимание MVC
Т. к. в найденной мной технической документации используются весьма заумные формулировки (типа «использует модель и представление для реализации необходимой реакции»), считаю необходимым написать свое понимание концепции MVC (чтобы не возникало недоразумений).
Итак, согласно концепции MVC, приложение должно состоять из 3-х фундаментальных логических частей: controller (контроллер), model (модель), view (представление/отображение). Блок controller – преобразует действия пользователя (в данном контексте, пользователь – не обязательно человек) во входящие параметры для Model и передает управление в Model. Блок model – реализует всю логику работы программы и подготавливает данные для отображения. Блок view – визуализирует результаты работы программы. Каждое действие пользователя всегда запускает цепочку controller->model->view.
Распишем функции каждого блока более подробно, controller:
  • загружает переменные окружения (POST/GET переменные, параметры командной строки, URL параметры и т. д.);
  • выполняет первичную обработку переменных окружения (проверка типов переменных, их наличие, установка значений по умолчанию и т. д.);
  • реализует механизмы контроля за внештатными ситуациями;
  • реализует механизмы логгирования (не аутентификации, а ведение журналов).

Model:
  • выполняет конечную проверку входящих параметров (допустимость значений, диапазонов и т. д.);
  • реализует взаимодействие с системами хранения данных (базы данных, файлы, SOAP и т. д.);
  • реализует логику работы программы;
  • подготавливает данные для визуализации.

View:
  • организует механизмы визуализации результатов работы программы.

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

Недостатки концепции MVC
1. Необходимость использования большего количества ресурсов. Сложность обусловлена тем, что все три фундаментальных блока являются абсолютно независимыми и взаимодействуют между собой исключительно путем передачи данных. Controller должен всегда загрузить (и при необходимости создать) все возможные комбинации переменных и передать их в Model. Model, в свою очередь, должен загрузить все данные для визуализации и передать их во View. Например, в модульном подходе, модуль может напрямую обрабатывать переменные окружения и визуализировать данные без загрузки их в отдельные секции памяти.
2. Усложнен механизм разделения программы на модули. В концепции MVC наличие трех блоков (Model, View, Controller) прописано жестко. Соответственно каждый функциональный модуль должен состоять из трех блоков, что в свою очередь, несколько усложняет архитектуру функциональных модулей программы.
3. Усложнен процесс расширения функционала. Проблема очень схожа с вышеописанной. Недостаточно просто написать функциональный модуль и подключить его в одном месте программы. Каждый функциональный модуль должен состоять из трех частей, и каждая из этих частей должна быть подключена в соответствующем блоке.

Преимущества концепции MVC
1. Единая концепция системы. Несомненным плюсом MVC является единая глобальная архитектура приложения. Даже в сложных системах, разработчики (как те, которые разрабатывали систему, так и вновь присоединившиеся) могут легко ориентироваться в программных блоках. Например, если возникла ошибка в логике обработки данных, разработчик сразу отбрасывает 2-блока программы (controller и view) и занимается исследованием 3-го (model). Я не раз удивлялся, насколько сильно упростилась локализация проблем.
2. Упрощен механизм отладки приложения. Т. к. весь механизм визуализации теперь сконцентрирован в одном программном блоке, упростились механизмы опционального вывода графических элементов. Я не могу оценить насколько это утверждение применимо в программировании классических приложений, но в Web программировании эта архитектурная особенность стала несомненным плюсом.

Выводы
Общее впечатление, от использования концепции MVC, получилось положительным. Те сложности, которые обратили на себя мое внимание - они больше психологические (вот всегда было так, а теперь по другому). В тоже время, для меня остался открытым вопрос, насколько можно применить концепцию MVC при разработке обычных приложений (например, для Windows). На вскидку вроде можно, но не факт, что это будет оптимально.
Ну и самый главный вопрос: стану ли я использовать концепцию MVC в следующих своих проектах? Ответ: думаю да.
авторский материал mvc php
комментарии - 0
от новых к старым | от старых к новымрегистрация/вход
<1>