У меня есть этот вариант использования.
- вызывающие абоненты (API в одном микросервисе или на разных микросервисах) хотят сообщать о различных КЛЮЧАХ и ЗНАЧЕНИЯХ в качестве аудита как часть их методов.
- Существует высокая вероятность того, что некоторые из KEYS будут очень распространены, о чем может сообщить большинство вызывающих абонентов.
- согласованность ОБЯЗАНА при использовании KEY NAME от нескольких вызывающих абонентов для сообщения одного и того же KEY.Пример: если все хотят сообщить идентификатор потребителя, то все вызывающие абоненты должны использовать ключ «customerId» только для обеспечения согласованности между разными вызывающими абонентами.
- Может иметь некоторый повторно используемый класс enum для хранения всех общих ключей, как указано выше, чтобы каждыйабоненты могут использовать.У вызывающих абонентов по-прежнему могут быть свои собственные пользовательские KEYS, о которых они хотят сообщить.
- Все вызывающие абоненты не должны выполнять дублирующиеся задания, например, если caller1, caller2 хочет сообщить customerID (общий KEY), тогда я не хочу, чтобы оба определяли классс параметром customerID в качестве свойства, а затем преобразовать его в JSON.
Я решил использовать приведенную ниже реализацию.
Enum для хранения общих KEYS
public enum EnumKeys implements Key {
CONSUMERID("consumerId")
...
...
...
}
Общий класс, который каждый вызывающий абонент может использовать для сообщения КЛЮЧ И ЗНАЧЕНИЕ @JsonPropertyOrder (alphabetic = true) открытый класс ReportData {
private Map<String, Object> properties = new HashMap<>();
@JsonAnyGetter
public Map<String, Object> getProperties() {
return properties;
}
public void setProperties(Map<String, Object> properties) {
this.properties = properties;
}
public ReportData add(Key key, Object value){
properties.put(key.getKeyName(), value);
return this;
}
Caller 1 Reporting consumerID
ReportData reportData = new ReportData();
reportData.add(EnumKeys.CONSUMERID,"123");
Вызывающий абонент 2 Сообщающий идентификатор потребителя
ReportData reportData = new ReportData ();reportData.add (EnumKeys.CONSUMERID, "435");
Звонящий 3 Отчетный XYZ-ключ, который не является общим
//First create a custom KEY
public enum CustomEnum implements Key{
XYZ("xyz");
}
ReportData reportData = new ReportData();
reportData.add(CustomEnum.XYZ,"custom value");
Наконец, среда будет преобразовывать каждый ключ свойствасопряжение с JSON
ObjectMapper mapper = new ObjectMapper().writeValueAsString(reportData);
Вывод
- Не всем вызывающим программам необходимо создавать класс держателей (эквивалентный ReportData) для хранения свойств.
- Используя экземпляр ReportData, они могут обеспечить согласованность при использовании того же имени KEY для KEY
- Вызывающие абоненты могут расширять EnumKeys (основной список KEYs) и определять свои собственные ключи и по-прежнему могут использовать тот же способ отчетности.
Вопросы
- Есть ли что-то плохое в этом способе использования?
- Что-то плохое для создания экземпляра объекта (ReportData) из HashMap /EnumMap?
- Является ли объект (с элементами экземпляра) лучше для создания JSON или HASHMAP с более ограниченным KEY NAME лучше?Конечный пункт назначения - JSON.
- Любой простой способ использовать существующий класс (с n свойствами) и использовать с классом ReportData.
Любой ввод приветствуется.