Дмитрий Энтелис

это личное дело каждой команды. можно, например, git flow

вы путаете инверсию контроля и инверсию зависимости. Давайте по порядку кратенько.

Зачем нам нужны контроллеры или различные представления данных

Зачем нам в принципе контроллер? Что он делает? Для упрощения не будет воспринимать контроллер как "один объект" и вместо этого представим себе его как целый слой. Так же заменим слово "модель" словом "приложение".

Задача контроллера - принять и обработать запрос и выдать ответ. По сути в контексте WEB наш HTTP запрос и ответ это представление, которое хочет получить клиент (браузер, мобильное приложение, SPA, что угодно). HTTP - это интерфейс пользователя (UI) для нашего web-приложения.

Например что бы независеть от реализации клиента и что бы было удобно мы передаем даты в формате iso 8601 (пример: 2016-07-14T19:40:12Z). Это удобно что бы быть независимым от реализации клиента или сервера. Но это не удобно для нашего приложения. В приложении скорее всего нам удобнее всего работать с объектом типа DateTime. То есть приложение использует абсолютно другое представление.

Мы могли бы прямо в приложении конвертить DateTime в iso 8601 но тогда мы делаем наше приложение привязанным к одному конкретному представлению, которое хочет получить клиент. К примеру по каким-нибудь причинам известным только темным богам, вам вдруг понадобится быстро прикрутить интеграцию с другим сервисом и те же данные гонять уже в RFC2822. И стало быть уже приложению нужно париться о еще одном представлении.

Мы могли бы сделать какие-то адаптеры у приложения, и дергать их в зависимости от потребностей, но тогда опять же наше приложение все еще знает о представлении, которое ему собственно не нужно. То есть у нас есть зависимость приложения от его UI что... похоже на "не лучшую идею". И тут на помощь приходит Inversion of Control.

Что такое Inversion of Control

Тут название само говорит за себя. Допустим у нас был объект A который дергал объект B, причем объект A по сути и не должен ничего знать об объекте B потому то это не его дело. Принцип инверсии контроля говорит нам о том, что в таких ситуациях именно B должно вызывать A, таким образом меняя направление потока управления. Это позволяет нам уменьшить связанность и повысить зацепление компонентов нашей системы. Так же сделав это у нас может появиться объект C который так же будет дергать объект A. Если говорить о UI - мы просто можем сделать несколько реализаций UI.

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

Роутер и контроллеры как реализация UI

Что бы отвязать приложение от логики формирования представления, вынесем это все в отдельный "слой" и назовем этот слой - контроллеры. Точнее это будет как цепочка адаптеров. Один адаптер (фронт-контроллер по сути) получает Request и делает какие-нибудь вещи с ним. Например проверяет можем ли мы вообще делать подобный запрос. Другой адаптер вызывает роутер и выясняет какой дальше адаптер вызвать. Если следующий адаптер не вызван - надо вернуть 404-ую ошибку. Если же все пошло хорошо - мы вызываем еще один адаптер, который уже будет конвертировать HTTP запрос в какое-то действие приложения (вызов метода приложения по сути).

Так а инверсия зависимости это что?

Инверсия зависимости - очень похожа на инверсию контроля но действует чуть по другому. Проще всего будет вглянуть на картинку:



стрелочка зависимости на первой фигуре выходит за пределы нашего "модуля" и залазит в "чужой", тем самым наш модуль становится зависимым от другого модуля. Яркий пример - у нас есть например SwiftMailer для отправки почты. Нашему коду нужен просто способ отправлять сообщения, а SwiftMailer просто конкретная реализация.

Если мы не хотим завязываться на SwiftMailer, и дать возможность в будущем изменить способ отправки почты, мы можем в рамках нашего модуля объявить интерфейс а в другом модуле уже его реализовать с применением SwiftMailer. Для упрощение под модулями мы можем понимать неймспейсы например.

Нужно ли соблюдать принцип инверсии зависимости в случае контроллеров?

Нет. Контроллеру нужна конкретная реализация какой-то части нашего приложения (ибо приложение главнее UI-ки), иначе в них нет особо смысла. И наше приложение вообще не должно париться о том что есть какие-то там контроллеры.

будет ли правильным передавать зависимости в роутинге

Это уже вопрос реализации IoC. Конкретно вы хотите получить что-то вроде Dependency Injection. Вы можете забрать зависимости из аргументов метода экшена. или аргументов конструктора контроллера.... или просто использовать контейнер зависимостей внутри контроллера.... это совершенно не важно. Контроллеры это то место где высокая связанность на компоненты фреймворка более чем допустимы.

С другой стороны у вас теперь роутинг совмещает обязанность маршрутизации и разруливания зависимостей. Сами понимаете что это как-то нарушает прицип единой ответственности. Этим может заниматься Controller Resolver какой-нибудь.

И тут выясняется, что ребята совсем нигде(!) не используют транзакций при записи связанных данных. И внешних ключей нигде(!!) в бд не ставят.

Либо какие-то просветленные, либо дети NoSQL-эры. Скорее всего второе.

На мои аргументы, что это угрожает целостности данных отвечают, что целостность должна контролироваться на уровне кода самого приложения.

Да, должна контроллироваться на уровне приложения. Но в большинстве случаев это не повод отказываться от внешний ключей и прочих средств контроля целостности. Да, я видел, что некоторые вендоры НЕ используют ограничения целостности в релизных версиях продуктов, но это скорее исключение, чем правило. И да, самое главное - в большинстве случаев данные живут дольше, чем приложение, с ними работающее. Или - также не редкость - приложений, работающий с одной базой - несколько. Тогда вам рано или поздно захочется дополнительный уровень "доверия", т.е. контроля целостности. Вы должны понимать, что неконсистентные данные в базе - это как правило большой или очень большой гемор, т.к. после появления таких данных в базе очень непросто понять, что они там делают, и что ВАМ теперь с ними делать.
Ограничения целостности снимают только если они заметно снижают производительность БД, её (производительности) не хватает, других способов быстро поправить ситуацию нет, и у вас на данный момент уже есть хоть какая-то уверенность, что приложение не накосячит в БД.

А теперь последнее. Целостность данных - не единственное, и даже не главное, для чего нужны и полезны транзакции. Дмитрий Энтелис классно написал про профнепригодность: попросите своих коллег написать биллинг кому-нибудь, выкатить его в продакшн, а потом объяснить начальнику отдела и директору, почему у некоторых клиентов, купивших две услуги по 500, списалось только за одну услугу. Можете рассказать коллегам про уровни изоляции - тут кстати навалом примеров.

В том, чтобы уменьшить размер скрипта и сайт быстрее работал.

Здесь проблема в том, что для всех процессов свои глобальные переменные, а нужно их как-то обобщить, если один процесс что-то изменяет в глобальных переменных - то это изменение должно продублироваться для всех процессов.

Горизонтальное масштабирование в первую очередь предполагает возможность развернуть приложение на N количестве физически удаленных компьютеров. Соответственно вы не можете изменить что-то локально таким образом чтобы при этом оно продублировалось для всех процессов на всех удаленных машинах. Увы, но магии не существует. Чтобы это было возможным, требуется реализовать какой-нибудь механизм межпроцессного взаимодействия. Один из них вы уже назвали - использовать для этих целей redis.

Но ваша проблема в другом. В архитектуре. Её нет. Код выше - это спагетти-код. Поэтому вы думаете, что вам нужно это

если один процесс что-то изменяет в глобальных переменных - то это изменение должно продублироваться

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

Вообще наличие большого количества глобальных переменных - это один из показателей плохого кода.

Вы можете продолжать городить костыли и накапливать технический долг сохраняя глобальное состояние в redis или прокидывать данные из дочерних процессов в мастер-процесс и наоборот (благо в node.js есть для этого инструменты), но все же лучше начать что-то изучать из области архитектурных решений в вебе (и в javascript в частности) и смотреть код других крупных проектов и желательно не только в javascript.

Думайте над архитектурой. Начните с того, как сделать так, чтобы отпала нужда в этих диких манипуляциях с глобальными переменными.

Не так важно разрешение экрана, как его размер. От чтения с экрана очень мелкого текста глаза устают на порядок сильнее, чем от мифических "здоровых пикселей, лезущих в глаза" :)