Открыть список
Как стать автором
Обновить

Разговор о MVC и архитектуре веб-приложений

PHPПрограммированиеПроектирование и рефакторингIT-стандартыAPI
MVC паттерн давно уже на рынке, но многие его используют по разному.

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

Основная цель — это выполнить проект в сроки и в дальнейшем развивать его вкладываясь в запланированный бюджет.

Один из важных критериев качества кода — это его простота. Но как измерять простоту? Один из вариантов — это рассчитать кол-во элементов системы. Чем меньше элементов тем система проще.

Допустим бизнес логику меньше сделать нельзя, так как она зависит от бизнеса, а не программиста, разве что можно ее оптимизировать. Тогда критерий будет — кол-во кода НЕ бизнес-логики. С опытом разработки мы увидели, что очень удобно разделить MVC таким образом:

Core Components
Server Environment needs
Routing
Common Libraries
M (Controller can connect with different objects):
2nd layer of business-logic
Get, Set, Data processing
HMVC Contollers
Adapters (for easy work with other services)
V = templating, head, footer-scripts, parts
C = easy code and first layer of business logic

+L = Libraries (for advanced and third-party components)

Модель многие понимают как работу с данными и это может быть как получение данных из базы так и целый внутренний сервис или сборка MVC компонента для вставки во view. Желательно, что бы они были НЕ сильно связаны и код можно было легко расширять.

View в веб-разработке часто несёт в себе заголовки head и скрипты, которые не являются уже внешним видом, а несут отдельный смысл. Лучше их переносить в отдельные файлы. Также View-ки должны легко делится на части для простоты масштабирования проекта

Controller — это основной элемент всей связки. В нем происходит распределение реакций на запросы клиента. И часто на первом этапе это распределение выполняет Rotuting, а уже потом в методе контроллера собираются все нужные данные и помещаются во View.

Мы считаем такую архитектуру оптимальной. Каждое направление может использовать ООП, наследовать абстрактные классы и усложнятся, но важно соблюдать границы, что бы код легко расширялся и был удобный для коллективной работы.

Многие фреймворки поддерживают такую архитектуру и многие аккуратные разработчики приблизительно так и строят программы.

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

Спасибо за внимание.

Если кто знает другие хорошие варианты архитектуры, напишите пожалуйста в комментах ваши мнения, спасибо.
Теги:mvcphpsoasoftware architecture
Хабы: PHP Программирование Проектирование и рефакторинг IT-стандарты API
Всего голосов 30: ↑9 и ↓21 -12
Просмотры18.7K

Комментарии 84

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Похожие публикации

Junior PHP Software Engineer
до 100 000 ₽Aviakassa.ruСевастопольМожно удаленно
PHP-разработчик/PHP-программист (удаленно)
от 60 000 до 120 000 ₽CreativePeopleСевастопольМожно удаленно
PHP developer
от 140 000 ₽PerAreМожно удаленно
PHP-разработчик (Middle)
от 130 000 до 170 000 ₽LAPTOP.RUМоскваМожно удаленно
PHP developer (Symfony)
от 100 000 до 200 000 ₽SibedgeСанкт-ПетербургМожно удаленно

Лучшие публикации за сутки