Должен ли внутренний API хранить информацию о макете?
Мне нужно создать систему для хранения и обслуживания информации по вопросам опроса. Учитывая множество вопросов, типов полей и их расположения, мне нужно предоставить данные, необходимые внешнему интерфейсу для отображения полей.
Одной из моих больших проблем является информация о макете. Я не уверен во всех способах расположения полей. Как минимум, мне нужно поддерживать такие вещи, как два текстовых поля, появляющиеся в 1 строке, а третье — в следующей строке. Или 6 ответов с несколькими вариантами ответов, расположенных в 2 столбцах по 3 строки.
Уместно ли хранить эту информацию о макете в моей базе данных и использовать ее вместе с данными вопроса/поля? Я думаю, что это мои 3 варианта. Любые мысли об этих вариантах были бы очень полезны или предложения по другим вопросам, которые следует учитывать:
- Я мог бы хранить индикаторы того, что в вопросе используется макет столбца, и давать каждому полю подсказки относительно того, в какой строке/столбце он находится.
- Я мог бы хранить что-то вроде CSS или шаблонов усов, чтобы определить макет.
- Я мог бы полностью оставить это на передний план. Я мог бы вернуть данные опроса и ожидать, что внешний интерфейс справится с любыми проблемами макета.
Вы можете транспонировать ту же структуру, которую вы получили бы с помощью XML, во что-то вроде JSON, но это было бы гораздо более болезненно.
Ответы 1
Общий ответ/совет, который я бы дал, — нет. Если вы поместите какую-либо информацию о макете в базу данных, вам будет очень сложно создавать новые функции, расширять предложение вашего продукта в будущем, поддерживать несколько интерфейсов (мобильное, прогрессивное веб-приложение, основной веб-сайт) и выполнять редизайн в будущем.
Я бы выбрал вариант C. Оставьте его на переднем конце. Вы можете легко сохранить «тип» вопроса, который может сопоставляться с шаблоном во внешнем интерфейсе, возможно, это позволит различным внешним интерфейсам отображать этот тип шаблона в соответствии с потребностями дизайна. И позволит вам легко развивать дизайн в будущем, последнее, что вам нужно, если вы хотите сделать редизайн, - это нуждаться в сценариях обновления БД, чтобы попытаться «исправить» css и отобразить данные.
Очевидно, мне не хватает полной картины того, чего вы пытаетесь достичь, дорожной карты вашего продукта и ваших будущих идей, но я, честно говоря, не могу представить себе сценарий, в котором хранение css в БД было бы хорошей идеей.
Я надеюсь, что вы найдете это полезным, мне было бы интересно услышать, как вы решите продвинуться в этом.
Сталкиваясь с этим несколько раз, XML — отличный формат для этого. На данный момент это, вероятно, непопулярное предложение, но мне несколько раз приходилось принимать одно и то же решение, и оно очень хорошо отвечает всем требованиям.