Должен ли бэкэнд API хранить информацию о макете? - PullRequest
1 голос
/ 13 марта 2019

Мне нужно создать систему для хранения и предоставления информации по вопросам опроса. Учитывая различные вопросы, типы полей и расположение полей, мне нужно предоставить данные, необходимые внешнему интерфейсу для отображения полей.

Одна из моих больших проблем - информация о макете. Я не уверен, как все поля могут быть расположены. Как минимум, мне нужно поддерживать такие вещи, как два текстовых поля, которые появляются в 1 строке, а третье - в следующей. Или 6 ответов с несколькими вариантами ответов, расположенных в 2 столбца по 3 строки.

Уместно ли хранить эту информацию о макете в моей базе данных и предоставлять ее вместе с данными вопроса / поля? Я думаю, что это мои 3 варианта. Любые мысли по поводу этих вариантов будут очень полезны, или предложения по другим вопросам:

  • Я мог бы хранить индикаторы того, что вопрос использует макет столбца, и давать подсказки каждому полю относительно того, в какой строке / столбце он находится.
  • Я мог бы хранить что-то вроде CSS или шаблонов усов для определения макета.
  • Я мог бы оставить это полностью переднему концу. Я мог бы вернуть данные опроса и ожидать, что внешний интерфейс справится с любыми проблемами макета

1 Ответ

0 голосов
/ 21 марта 2019

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

Я бы выбрал вариант С. Оставьте его переднему краю. Вы можете легко сохранить «тип» вопроса, который может отображаться в шаблоне во внешнем интерфейсе, возможно, это позволит различным интерфейсам визуализировать этот тип шаблона в соответствии с требованиями дизайна. И позволит вам в будущем легко разрабатывать дизайн. Последнее, что вам нужно, если вы хотите сделать редизайн, - это необходимость сценариев обновления БД, чтобы попытаться «исправить» CSS и отобразить данные.

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

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

...