Дизайн Вопрос (ы) - Обработка шаблона с версиями и интерфейсом выставить версию и тип - PullRequest
Новая
       32

Дизайн Вопрос (ы) - Обработка шаблона с версиями и интерфейсом выставить версию и тип

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

Это звучит неправильно в дизайне?Я пытаюсь найти наиболее гибкий способ обработки шаблона, который может быть изменен с течением времени.Например, с первой версии шаблон приложения может иметь 10 полей.Следующая версия шаблона может иметь 15 полей.Проблема не столько в добавлении полей, сколько в удалении / изменении значения имени поля.Шаблон будет сохранен как представление JSON.Поэтому хранение в базе данных с различными вариациями не является проблемой.Проблема в том, как лучше всего представить это в принципах ОО дизайна.Кроме того, в классическом Spring MVC с представлениями JSP, как лучше всего обрабатывать различные варианты хранимых шаблонов во времени?

Я думал, если я сохраню версию и введите в базе данных запись (JSON).

Чтобы сделать это в моем базовом интерфейсе (интерфейс, похожий на маркер), у меня есть 2 метода String getVersion () и getType (), что было бы неправильно с учетом принципов проектирования?Если я сделаю это, я могу запросить зависимости типа для любого дочернего класса при извлечении этих объектов из базы данных.Представьте, что объект хранится в виде плоской структуры (JSON) в базе данных.Например -> findXTypes () как метод.В реализации метода я могу найти с помощью Type = '. Tostring ()' в запросе.

При их просмотре это усложняется. Я могу сделать это в контроллере с помощью @RequestMapping (value = "/ myTemplate", method = RequestMethod.GET) public String showRecord (@RequestParam ...) {.... return "myTemplate" + Type + TemplateVersion;}

Тогда мне нужно будет ввести новый JSP (View) для каждой версии.Не очень хорошо, я знаю, но в противном случае мне пришлось бы обрабатывать версию в выражениях IF в том же виде, что было бы более сложно.

Есть хорошие идеи?

1 Ответ

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

Трудно понять, о чем вы спрашиваете.Но я думаю, что вам нужно четко отделить требования от дизайна.

Я предполагаю, что ваши "шаблоны" на самом деле являются формами или страницами отчетов, которые вы должны представить пользователям.Или что между этими шаблонами и формами / отчетами существует отношение 1 к 1.

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

  • Если да, то очевидно, что вам нужно несколько JSP (или шаблонов, или что-то еще) с одним для представления каждой версии, которую вы в настоящее время поддерживает.

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

Архитектура: если вам требуется поддержка нескольких версийВ шаблоне одновременно существует два основных подхода:

  • Иметь один класс сервлета, который обрабатывает все версии шаблона, и одно представление, которое отображает их все.Вероятно, это должно быть "управляемым данными".Вы должны хранить дескриптор для полей, которые будут обрабатываться для каждого шаблона, и кодировать классы сервлетов для выполнения запросов и отображать результаты исключительно в зависимости от того, что находится в дескрипторах.(Дескрипторы могут быть сохранены в базе данных.)

    Проблема этого подхода в том, что он сложный.И это еще сложнее, если вам нужно реализовать инфраструктуру для представления дескрипторов, обработки информации и визуализации результатов для себя.

  • Написать отдельный класс сервлета и / или JSP для каждого шаблонаи диспетчеризация между ними на основе (например) пути или параметров URL.

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

...