Алексей: оптимизируйте то, с чем есть проблемы. Конкретно вашу проблему база данных сама по себе не решит. Вопрос в модели данных, как вы это дело храните, какие выборки вам надо делать. Вам надо оптимизировать количество записей которые нужно обходить при выборках. А это индексы, агрегации, и тд.
Андрей Безруков: контроллеры не будут толстыми. DRY и все такое. Можно мэпить запрос на отдельные объекты и реализовывать валидацию на этом уровне (в laravel вон есть FormRequest-ы), можно на уровне мидлвэров, можно еще как.
Суть тонких контроллеров в том, что у вас должен быть один вызов метода одного сервиса на экшен контроллера. Или два (если у нас разделено чтение и запись на два разных сервиса)... или в цикле если пакетная обработка. Но суть в том, что бы делигировать выполнение другой штуке, а сам контроллер может только конвертить данные из формата HTTP в формат модели.
Я бы рекомендовал вам просто не загоняться по MVC, максимум почитать про separation of concerns и smartui (как антипаттерн).
Aracon: в контексте запроса - оно может быть валидным. Более простой пример - проверка email на уникальность. На уровне валидации в контроллере - мы проверяем только является ли строка email-ом и заполнено ли оно. А проверять уникальность будет уже модель при попытке сохранения или же отдельно в репозитории, когда мы сохраняем объект. То есть по хорошему валидация должна происходить в контроллере, а если данные пошли дальше - дальше их должны хэндлить бизнес правила и органичения.
Илья Трусов: когда люди начинают говорить о базе данных в контексте MVC - все сразу становится сложнее. И тут либо человек не понимает что такое MVC либо под этими тремя буквами подразумевает какой-нибудь Model2.
модель это не "только база и все", это огромный слой который содержит как данные так и поведение по работе с этими данными. Неужели надо опять писать статью в духе "что такое MVC или зачем нам separation of presentation".
Артем Кустиков: данные нужно иметь в готовом виде, именно так. А вот http.request - это как раз таки надо что бы эти данные получить. Собственно с этим нет абсолютно никаких проблем и именно об этом и нужно думать когда проектируешь изоморфное приложение. Работа с состоянием полностью отделено от представления.
copal: json - это значение. Пока мы не мутируем значение - у нас нет концепции времени и следовательно какого либо состояния. Все как в математике.
Конечно же в реальности совсем без состояний никак, но можно идти на ухищрения. Например представлять состояние как коллекцию действий (event sourcing, flux, redux), или же заворачивать какие-то stateful штуки в монады. Но это уже усложнение большое.
Лично мне нравится идея совмещения ОО подходов и функциональщины (минимизация мутаций).
copal: вы же понимаете что "класс" с одним статическим методом-фабрикой это как бы все та же функция?
У вас в голове какая-то идея-фикс на тему того, что все должно быть в контексте классов, хотя все внимание должно уходить на взаимодействие объектов. А так как функция - это объект, то не вижу ничего такого, что мы можем юзать чисто их. Тем более если у нас вообще нет состояния (только поведение).
С другой стороны я не вижу смысла писать в продакшен на каком-нибудь haskell, разве что мы не занимаемся математикой и т.д.
Это компиляторы должны код оптимизировать и выявлять-устранять утечки, а не программисты.
А как же локи, сокеты, ресурсы, пайпы, шаред мемори? Компилятор вам ничего не должен. Да и весьма просто можно сделать утечку памяти даже в языках со сборщиками мусора.
Что до свитчей и т.д. - есть такая штука как patternmatch. Распростаренное заблуждение что ООП придумали что бы избавиться от свитчей/if-в, на самом деле их просто "прячут".
terrier почитайте про агрегаты транзакций и задумайтесь, нужен ли механизм транзакций если вы оперировать в рамках одной бизнес транзакции должны всегда только независимыми документами. Атомарность в этом случае нам гарантирована, а мы можем строить любую структуру, котоаря нам вздумается.
Проблемы начинаются только тогда, когда появляются связи между различными агрегатами транзакций. Это означает, что мы не верно выделили агргегаты, или же просто монга тут не подходит (графы например).
copal: давайте вспомним зачем понадобились объекты. Объекты понадобились что бы "спрятать" мутируемое состояние и расположить поведение поближе к оному (гуглить про high cohesion). А если у нас нет состояния, достаточно обойтись модулями и функциями.