• Преимущесва регистрации
    Post
    Специальный цены, бонусы и подарки.
    Post
    История заказов, ваши данные, расширенные комментарии.
    Post
    Быстрый заказ с сохранением данных, доп. опции заказа.
EN / RU

Расширенная MVC архитектура программы

Дата публикации: 2016-04-10 от torrison1 в Project Management PHP Back-End Programming
Расширенная MVC архитектура программы

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

 

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


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


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

 

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

​​​​Core Components 
Server Environment needs
Routing
Common Libraries
M (Controller can connects with different objects):
2th 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 в веб-разработке часто несёт в себе теги в заголовке и скрипты, которые не являются View и они должны отделятся в отдельные файлы.

 

Также view должно легко делится на части для масштабирования проекта.

 

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

 

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

 

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

 

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

 

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


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


Комментарии

Комментарии могут оставлять только зарегистрированные пользователи

Регистрация