Максим Федоров

Ох...

Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.



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

View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.

Прочитал комментарии - фигней вы занимаетесь. Конкретная задача есть? Если нет - тогда к чему сотрясать клавиатуру, накидывая конфиг?
Есть такое понятие - "преждевременная оптимизация". Вам почти любой, кто с этим сталкивался, скажет, что преждевременная оптимизация - это плохо.
Как сказал Игорь Сысоев в одном из докладов - "Фактически настройка nginx сводится к выставлению worker_processes в число железных ядер на машине, или в auto, а дальше надо заниматься тюнингом самой системы".
С моей колокольни, обычно первоначальная настройка выглядит так:
В nginx.conf

worker_processes auto;
worker_rlimit_nofile 65535;
worker_connections 65535;
accept_mutex off;

А потом в conf.d описываем первый виртхост с минимальным конфигом...
Запустили что надо в минимальной конфигурации, посмотрели на все это дело и уже только потом тюнить - включить gzip где надо, выставить опции к сокетам (включая http2, куда ж без него :-) ), выключение sendfile, где не надо, включение aio, где надо, включение thread-pool если ситуация требует, выкручивание буферов в крайних случаях.

По вашему конфигу - портянка получилась еще и потому, что многие опции дублированы в разных server, хотя можно было их вынести выше в секцию http, ssl-опции можно также почти полностью вынести в секцию http (в вашем случае можно вообще некоторые опустить).