Versiones de archivos de datos simples con DataContractSerializer

Question

Al haber leído Data Contract Versioning, hemos llegado a la conclusión de que no es realmente la historia completa. Por ejemplo, ¿qué sucede si solía tener ValueA, y en la nueva versión ahora se llama ValueB y es de un tipo diferente, y necesita convertir ValueA en ValueB?

Hay algunos callbacks que podría utilizar para ayudar con esto, pero no parece una solución muy fácil de mantener si esperamos que el formato cambie con frecuencia durante un largo período de tiempo.

La solución que establecimos es mantener un campo "guardado por versión", y al cargar las rutinas de conversión de invocación de archivos específicas para las versiones anteriores según sea necesario. Estas rutinas de conversión saben cómo convertir XML para datos más antiguos a XML para datos más nuevos.

Sin embargo, como resulta, DataContractSerializes requires the order of the elements to be exactly what it expects. Esto significa que nuestro proceso de conversión debe saber insertar elementos en exactamente la ubicación correcta. Esto es mucho más difícil que simplemente agregar un elemento con un nombre conocido, si se tiene en cuenta la herencia. Con la herencia, no se puede o AddAfterSelfcampo de manera confiable, simplemente porque no hay un solo campo que esté siempre al lado de este nuevo campo.

Dejando de lado las razones por las que DataContractSerializer se hizo tan estricto, ¿puede sugerir formas de evitar esto? Tal vez un excelente artículo sobre cómo permanecer compatible con versiones anteriores de contratos de datos muy antiguos, que no se vuelven difíciles de manejar en el momento en que realizó el cambio número 100 al formato.

Hay algunas pautas adicionales en this article, pero esto debe haber sido escrito para un propósito diferente. Por ejemplo, no hay forma de que podamos dejar a los viejos miembros de datos rondando por siempre (punto 9). Parece que la mayoría de dichos artículos se escriben desde el punto de vista del protocolo de comunicación, en lugar de almacenar datos en un archivo.

Answer 1

Creo que está esperando demasiado del soporte de versiones incorporado. Realmente tiene la intención de permitirle agregar nuevos miembros al tiempo que conserva todas las funciones existentes y, por lo tanto, los miembros.

En caso de que se produzcan cambios en un contrato, es mejor que cree una nueva versión del contrato (por ejemplo, utilizando un nuevo espacio de nombres; una convención común es usar un sufijo aaaa/mm, por ejemplo http://mycompany.com/myservices/2009/10).

Luego debe ser capaz de admitir tantos contratos antiguos como sea apropiado, y debe poder convertir entre cada contrato admitido y la representación interna actual que esté utilizando.

Answer 2

1 año después, tengo que decir que DataContractSerializer realmente ha chupado para el control de versiones. Es demasiado rígido. En realidad, está destinado a contratos que probablemente no cambiarán, y solo en formas específicas. Tienes que hacer un trabajo extra para usarlo solo para hacerlo rápido, como el KnownTypeAttribute, por ejemplo. Solo lo recomendaría si necesita una serialización relativamente rápida, lo cual, podría decirse, es bastante importante para lo que fue diseñado.

Otro proyecto en el que trabajo utiliza un serializador más flexible que, por ejemplo, no omite llamar al constructor de clase (algo ha causado muchos inconvenientes) y no requiere que los elementos estén en un orden específico. Se ocupa con gracia de los nuevos campos (se dejan en lo que el constructor haya establecido) y elimina los campos con cero intervención del programador.

Ahora, si tan sólo pudiera publicarlo aquí ... Sin embargo, es aproximadamente 5x-10x más lento que el DataContractSerializer.