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


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.

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

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

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

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

Если кто знает другие хорошие варианты архитектуры, напишите пожалуйста в комментах ваши мнения, спасибо.

-->


К сожалению, не доступен сервер mySQL