Шаблон MVC присутствует на рынке уже давно, но многие люди используют его по-разному.
В чем проблема? Дело в том, что многие разработчики сильно усложняют код и тогда его поддерживать и развивать становится дорого, либо приходится делать глобальный рефакторинг, что весьма невыгодно для бизнеса.
Основная цель – завершить проект в срок и продолжить его развитие, инвестируя при этом в запланированный бюджет. Одним из важных критериев качества кода является его простота.
Но как измерить простоту? Один из вариантов – подсчитать количество элементов системы.
Чем меньше элементов, тем проще система.
Скажем, бизнес-логику нельзя уменьшить, поскольку она зависит от бизнеса, а не от программиста, если ее нельзя оптимизировать.
Тогда критерием будет количество кода, а НЕ бизнес-логика.
Имея опыт разработки, мы увидели, что MVC очень удобно разделить таким образом: Основные компоненты Требования к серверной среде Маршрутизация Общие библиотеки M (Контроллер может подключаться к различным объектам): 2-й уровень бизнес-логики Получить, Установить, Обработка данных Контроллеры HMVC Адаптеры (для удобной работы с другими сервисами) V = шаблон, заголовок, скрипты нижнего колонтитула, части C = простой код и первый уровень бизнес-логики +L = Библиотеки (для расширенных и сторонних компонентов) Многие понимают модель как работу с данными, а это может быть как получение данных из базы данных или целого внутреннего сервиса, так и сборка MVC-компонента для вставки в представление.
Желательно, чтобы они НЕ были сильно связаны и код можно было легко расширять.
Представление в веб-разработке часто несет в себе заголовки и скрипты, которые уже не являются внешним видом, а несут отдельный смысл.
Лучше перенести их в отдельные файлы.
Кроме того, представления должны легко делиться на части для облегчения масштабирования проекта.
Контроллер является основным элементом всей связки.
Он распределяет реакции на запросы клиентов.
И зачастую на первом этапе это распределение осуществляется Rotuting, а уже потом все необходимые данные собираются в методе контроллера и помещаются во View. Мы считаем эту архитектуру оптимальной.
Каждое направление может использовать ООП, наследовать абстрактные классы и усложняться, но важно соблюдать границы, чтобы код легко расширялся и был удобен для коллективной работы.
Многие фреймворки поддерживают такую архитектуру, и многие внимательные разработчики строят программы примерно таким образом.
Если в коде перепутаны рассмотренные выше элементы, то мы рекомендуем провести рефакторинг как можно скорее и тогда процесс разработки может значительно ускориться.
Спасибо за внимание.
Если кто-нибудь знает другие хорошие варианты архитектуры, напишите, пожалуйста, свое мнение в комментариях, спасибо.
Теги: #MVC #php #soa #архитектура программного обеспечения #php #программирование #проектирование и рефакторинг #ИТ-стандарты #api
-
Зодиак
19 Oct, 24 -
Linux В Екатеринбурге: Кино Для Себя
19 Oct, 24 -
Андроид И Все, Все, Все
19 Oct, 24 -
Схема Обработки Ошибок В Yii
19 Oct, 24 -
Менеджер Проекта Начального Уровня - Дизайн
19 Oct, 24 -
Когда Я Сказал...
19 Oct, 24
