> не нужно искать хэлпер для форматирования какого-то поля объекта
Форматтеры в модели, это как раз пример плохой богатой модели. Из-за таких моделей появляются подобные статьи. Модель богатая, потому что в ней описана вся ее бизнес логика, а не потому что в ней описано вообще все-все, что к ней относится. Форматирование, этой слой UI.
Как убедить: рассказать о плюсах лучшего кода. Ведь код-ревью вводится чтобы код стал лучше. Главное не зациклиться на самом коде, а вместо этого рассказать, что это даст бизнесу. Что увеличится скорость разработки (а не уменьшится), что в хороший код легче вносить изменения, что в такую фирму захотят прийти работать другие хорошие программисты, а не только говнокодеры.
Если такие аргументы не работают, значит нечего там делать.
Если в вашей фирме нет код-ревью и низкое качество кода, значит это устраивает и босса, и большинство программистов. Так же это вероятно значит, что изначально именно программисты начали разработку в таком стиле, боссу все понравилось, и зачем вдруг сейчас что-то менять, ему не очень ясно.
Раз вы работаете в этой фирме, значит вас в целом тоже все устраивает.
Если вы выросли и вас не устраивает, вы можете или попробовать стать архитектором этой системы (но нет гарантии что вам дадут применить ваше новое положение на практике), или найти новое место работы.
Мой опыт говорит, что если в фирме недостаточный уровень качества разработки, но бизнес как-то работает и зарабатывает, почти невозможно убедить сделать какие-то улучшения. И это как бы логично, зачем тратить время, если и так работает.
Насчет пункта 3, я долго извращался, выпиливал этот ArrayCollection на уровне репозитория (фактически, нужен кастомный гидратор, который будет вместо ArrayCollection создавать примитивный array).
В конце концов решил, что лучше пусть уж в конструкторе останется ArrayCollection, но во всех методах, которые с ним работают, переменная используется как будто она массив. Как меньшее зло, работает норм.
Можно еще так ответить. Представьте, что вы используете разделение на Command и Query в слое сервисов, даже если вы этого не делаете. И вот те обращения к БД, которые вы делали бы в Command если бы они у вас были, вы делаете через Репозиторий. А все остальные обращения — так как вам удобно.
Поместить там, где хочется. Начиная от обращения к базе прямо в контроллере заканчивая особым QueryRepository который содержит все эти запросы, которые мы часто где-то используем для вывода данных пользователю. По-умолчанию я бы выбрал эти данные где-то в сервисе или запросе (запросе из слоя сервисов, а не БД).
Момент просмотра модератором списка хабов, это еще не момент выполнения какого-то кода в бизнес-логике.
А вдруг, при реализации нашего чудо-репозитория мы воспользовались уникальными особенностями конкретного ORM?
А какая разница, какими особенностями мы воспользовались? У нас есть интерфейс, который говорит, что если попросить User UserOfId(UserId userId) то получим пользователя. Внутри конкретного репозитория это может быть сделано как угодно, главное, что в итоге есть User.
Очень многие используют репозиторий для получения вообще любых данных, хотя по идее репозиторий описывает то, что нужно бизнес-логике.
В интерфейсе репозитория, и в реализации соответственно, мы создаем такие методы, которые нам нужны для применения каких-то изменений к моделям. Если нам где-то нужно вывести постраничный список пользователей с разными условиями — это не имеет отношения к сохранению данных этих пользователей или манипуляцией их списком как одним целым. И в этой ситуации нам не нужны никакие репозитории, можно хоть прямо в базу запросы слать.
Интерфейс репозитория, это как документация, он сообщает нам, что, например, где-то есть бизнес-процесс, которому нужно получить всех пользователей с датой регистрации не позднее какого-то числа. И это нужно не потому, что мы хотим вывести это где-то в интерфейсе, а потому что мы будем проводить какие-то манипуляции с такими пользователями, принимать какое-то бизнес-решение. Если же нужно просто выводить список ограниченный по дате, используем то что удобно.
Форматтеры в модели, это как раз пример плохой богатой модели. Из-за таких моделей появляются подобные статьи. Модель богатая, потому что в ней описана вся ее бизнес логика, а не потому что в ней описано вообще все-все, что к ней относится. Форматирование, этой слой UI.
Если такие аргументы не работают, значит нечего там делать.
Раз вы работаете в этой фирме, значит вас в целом тоже все устраивает.
Если вы выросли и вас не устраивает, вы можете или попробовать стать архитектором этой системы (но нет гарантии что вам дадут применить ваше новое положение на практике), или найти новое место работы.
В конце концов решил, что лучше пусть уж в конструкторе останется ArrayCollection, но во всех методах, которые с ним работают, переменная используется как будто она массив. Как меньшее зло, работает норм.
Момент просмотра модератором списка хабов, это еще не момент выполнения какого-то кода в бизнес-логике.
А какая разница, какими особенностями мы воспользовались? У нас есть интерфейс, который говорит, что если попросить User UserOfId(UserId userId) то получим пользователя. Внутри конкретного репозитория это может быть сделано как угодно, главное, что в итоге есть User.
Очень многие используют репозиторий для получения вообще любых данных, хотя по идее репозиторий описывает то, что нужно бизнес-логике.
В интерфейсе репозитория, и в реализации соответственно, мы создаем такие методы, которые нам нужны для применения каких-то изменений к моделям. Если нам где-то нужно вывести постраничный список пользователей с разными условиями — это не имеет отношения к сохранению данных этих пользователей или манипуляцией их списком как одним целым. И в этой ситуации нам не нужны никакие репозитории, можно хоть прямо в базу запросы слать.
Интерфейс репозитория, это как документация, он сообщает нам, что, например, где-то есть бизнес-процесс, которому нужно получить всех пользователей с датой регистрации не позднее какого-то числа. И это нужно не потому, что мы хотим вывести это где-то в интерфейсе, а потому что мы будем проводить какие-то манипуляции с такими пользователями, принимать какое-то бизнес-решение. Если же нужно просто выводить список ограниченный по дате, используем то что удобно.