Comments 4
Не отношу себя к "опытным коллегам", но по ощущениям, вам не хватило кого-то уровнем мидла и выше, который сначала бы спроектировал API, а потом уже их реализовывали. Просто если внешний вид страницы и ее элементов зависит от возвращаемого типа из базы, то это выглядит не просто как нарушение принципов разработки, а как дичайшее надругательство. Отсюда и идут дальше все проблемы, но они уже следствие основной.
Возможно, мне не удалось донести что именно мы делали. Дело не во внешнем виде, а в динамическом содержимом. Нам нужно было сделать свой упрощённый аналог Google Forms, то есть динамическую форму, состав полей которой полностью контролируется через админ-панель. И, соответственно, данные, полученные из админки, мы хранили в БД.
EAV не антипаттерн, вполне себе нормальный паттерн, просто нужно понимать возможные проблемы, в первую очередь с производительностью.
В принципе во вью или запросе eav и в json/b можно собрать, относительно легко, если есть желание.
Здесь проблема не в паттернах а в Angular.
В идеальном мире у нас был бы код страницы, который запрашивает с сервиса список dto-шек с вопросами, из которых он делает список вьюшек swiitch-case-ом (спрятанным в фабрику или нет, не важно), с которыми работает пользователь. После того как пользователь нажимает кнопку сабмит, код страницы проходит по списку вьюшек, достает через виртуальную функцию из каждой новый dto и отдает список сервису для отправки на сервер.
Здесь у каждого класса своя ответственность: у сервиса только передача данных, у вьюшек - только редактирование, у страницы - инициализация и управление этим.
Дальше, нам нужно впереть все это в концепт ангулара не сильно покалечив.
Каждый класс вьюшек без вариантов становится компонентом ангулар.
Компоненты развертываются из списка dto с помошью *ngIf:
*ngFor="let q of questions"
<QuestionComponent1 *ngIf q.type = "Type1" [question]= q>
<QuestionComponent2 *ngIf q.type = "Type2" [question] = q>
Теперь вопрос - как достать данные из этих компонентов.
Фреймворки всегда имеют минусы и плюсы. Плюс - путь для решения пролем уже есть. Минус - этот путь в половине случаев не то что бы оптимален.
Для того, чтобы достать данные из компонентов нужен будет еще один объект - буфер для накопления результатов.
Он будет иметь один метод для приема dto от компонентов-влюшек.
Внутри он просто сохраняет/обновляет dto в словаре по некому ключу вопроса (номеру, например).
Второй его метод отдает результаты странице для отправки на сервер с помощью сервиса.
В конструкторе в этот класс-буфер можно передать исходный список dto, что позволит ему помимо прочего иметь функцию, возвращающую количество не отвеченных вопросов, чтобы код странциы мог определить можно ли уже сабмитить результат.
Вроде ничего не забыли.
Проверяем на сопровождаемость.
Для добавления нового типа вопросов достаточно добавить входную и выходную dto и компонет-вьюшку. Еще нужно добавить *ngIf. Код страницы, сервис и буфер менять не нужно.
Тесты:
Каждый компонент тестируется по сценарию - входная dto, набор кликов, выходная.
Буфер тестируется совсем просто и отдельно (если его вообще нужно тестировать).
В сервисе тестировать нечего.
Страница для тестирования требует мок сервиса, мок буфера и настоящие компоненты, если опять таки есть смысл ее тестировать.
В общем все выглядит изолированным и SOLIDным.
Как я выстрелил себе в ногу, не соблюдая паттерны