Предотвращение избыточности при доступе к данным статических таблиц для условного программирования

Question

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

Например: у меня есть база данных студентов, которая содержит статическую таблицу student_type (указывающую на трудолюбие, умные, ленивые и т. д. типа).В коде мне нужно принять меры на основе student_type.

Итак, мой код будет выглядеть так:

studentTypeId = student.getTypeId(); // student constructed from database
switch (studentTypeId)
{
    case HARDWORKING_ID :
       // do something
    case LAZY_ID :
       // do something
    break;
}

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

Спасибо.

Answer 1

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

studentTypeId = student.getTypeId(); // student constructed from database
switch (studentTypeId)
{
    case HARDWORKING_ID :
       // do something
    case LAZY_ID :
       // do something
    case SMART_ID :     // added smart student, very rare corner case :-)
       // do something
    break;
}

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

Если вы действительно действительноЕсли вы хотите уменьшить дублирование, вы можете использовать полностью подключаемую архитектуру, как это предложил Дэйв Ньютон.Это может быть реализовано как отношение id -> class name для каждого идентификатора.Затем вы создадите экземпляр класса, и вся логика, связанная с каждым идентификатором, будет содержаться в этом классе.Это не всегда легко или невозможно.Для вашего примера это вполне возможно, но если это не сделано правильно, это может быть сложно.

Кроме того, это не решит все ваши проблемы.Вам все еще нужно разработать Java, протестировать его и заново развернуть новый класс.Так что на самом деле объем работы, который вы бы сэкономили, может быть минимальным.

Часто легче принять небольшое количество дублирования и просто пойти на простое решение.

Answer 2

Если таблица student_type содержит только некоторые идентификаторы и, возможно, некоторый описательный текст, но не более того, как в этом небольшом примере

   ID    description
    1    'Hard worker'
    2    'Lazy snob'

, тогда ваш единственныйшанс состоит в том, чтобы использовать идентификаторы в вашем коде, возможно, давая им собственные имена, используя либо enum, либо некоторый постоянный интерфейс, как вы уже делали.И каждое изменение в `student_type ', которое требует изменения поведения , потребует изменения кода.Выхода нет, потому что единственное место, где поведение формализовано и определено, находится в вашем коде.

ЕСЛИ однако таблица имеет формализованное содержимое, как здесь

   ID    description    min_    max_   min_  max_  fire_   give_
                      points  points  grade grade  ASAP    kudos
    1    'Hard worker'   100     200      B     A     F        T
    2    'Lazy snob'       0      50      Z     Q     T        F
    3    'Medium'         50     100      P     C     F        F

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

    StudentType studentType = student.getStudentType();
    if( studentType.isGiveKudos() )
        doGiveKudos(student);
    if( studentType.isFireAsap() )
        doFire(student);
    // next student...

Это путь, если необходима гибкость.

царапина Теперь я не знаю, сильно ли это отличается от вопроса.

Answer 3

Существует множество способов, которыми это может быть реализовано.Для быстрого / грязного материала я буду часто хранить имя класса реализации в БД и просто создавать экземпляры во время выполнения.Иногда я сохраняю реализацию Groovy в БД.Иногда я буду использовать бобы Spring, где фабрика хранится в БД.Все зависит.