Problemas de serialização de tempo e desserialização

Boa noite, leitores.

Aqui, compartilhamos um problema que é frequentemente encontrado no desenvolvimento diário: o problema de serialização e desserialização do DateTime: se não for processado, haverá um problema de serialização e desserialização.

import org.joda.time.DateTime;

class CreateCouponCommand{
	private DateTime validFrom;

	private DateTime validUntil;
//省略get set方法
}

Existe algum problema com essa classe ao serializar ou desserializar? Geralmente não haverá; se você encontrar esse formato ao armazenar o banco de dados, haverá um problema:

validFrom": {
		"afterNow": false,
		"beforeNow": true,
		"centuryOfEra": 20,
		"chronology": {
			"zone": {
				"fixed": true,
				"iD": "UTC"
			}
		},
		"dayOfMonth": 7,
		"dayOfWeek": 2,
		"dayOfYear": 98,
		"equalNow": false,
		"era": 1,
		"hourOfDay": 3,
		"millis": 1586231107919,
		"millisOfDay": 13507919,
		"millisOfSecond": 919,
		"minuteOfDay": 225,
		"minuteOfHour": 45,
		"monthOfYear": 4,
		"secondOfDay": 13507,
		"secondOfMinute": 7,
		"weekOfWeekyear": 15,
		"weekyear": 2020,
		"year": 2020,
		"yearOfCentury": 20,
		"yearOfEra": 2020,
		"zone": {
			"$ref": "$[0].ToFvarom.chronology.zone"
		}
	},

Certamente não é isso que queremos, então qual é o problema?
De fato, o CreateCouponCommand acima é uma versão simplificada, o código real desse campo vaildUntil é
uma propriedade aninhada em uma lista, usamos JsonUtils.ObjectToString (), a camada inferior usa o fastjson para serializar esse objeto da lista, ou seja Esta lista corresponde a um campo no banco de dados: o
campo business_cmd deve idealmente se parecer com este após persistência:

[
	{
		"validFrom":"2020-04-10T11:32:04.000Z",
		"validUntil":"2020-04-10T11:32:04.000Z"
	},
	{
		"validFrom":"2020-04-10T11:32:04.000Z",
		"validUntil":"2020-04-10T11:32:04.000Z"
	},
]

A hora deve ser uma sequência de horas UTC, no entanto, o armazenamento real é assim:

[
	{
		"validFrom":{
		"afterNow": false,
		"beforeNow": true,
		"centuryOfEra": 20,
		"chronology": {
			"zone": {
				"fixed": true,
				"iD": "UTC"
			}
		},
		"dayOfMonth": 7,
		"dayOfWeek": 2,
		"dayOfYear": 98,
		"equalNow": false,
		"era": 1,
		"hourOfDay": 3,
		"millis": 1586231107919,
		"millisOfDay": 13507919,
		"millisOfSecond": 919,
		"minuteOfDay": 225,
		"minuteOfHour": 45,
		"monthOfYear": 4,
		"secondOfDay": 13507,
		"secondOfMinute": 7,
		"weekOfWeekyear": 15,
		"weekyear": 2020,
		"year": 2020,
		"yearOfCentury": 20,
		"yearOfEra": 2020,
		"zone": {
			"$ref": "$[0].ToFvarom.chronology.zone"
		}
	},
		"validUntil":"同上"
	},
	{
		"validFrom":"同上",
		"validUntil":"同上"
	},
]

Onde está o problema?
O que acontece se o fastjson não puder serializar e desserializar datas automaticamente? Em seguida, personalize a serialização e a desserialização em vez de deixar o fastjson fazer essas coisas automaticamente. Dê uma olhada na solução no método de anotação abaixo:


@ApiModelProperty(value = "过期时间")
    @JSONField(name = "validUntil", deserializeUsing = DateTimeJsonDeserializer.class, serializeUsing = DateTimeJsonSerializer.class)
    private DateTime validUntil;

Essa anotação do @JSONField ainda é fastjson, mas duas delas: desserialização, serialização são reescritas por você, o código específico não será mostrado, existem muitas soluções online e cada empresa também pode ter seu próprio método de processamento.

Antes de tudo, vi que o formato de armazenamento de datas estava errado e pensei imediatamente no problema da serialização de datas. Depende do que foi originalmente usado para serializar. Usamos fastjson. Esse é um problema com a data. O que devo fazer? Em seguida, personalize o processo de serialização.

Bem, até a próxima!

Publicado 181 artigos originais · elogiou 66 · 200.000 visualizações

Acho que você gosta

Origin blog.csdn.net/meiceatcsdn/article/details/105444889
Recomendado
Clasificación