c# - serializar - tipos de serializacion

Serializando vs Base de Datos (7)

Creo que la mejor manera de guardar el estado de su aplicación es con una base de datos relacional tradicional que la mayoría de las veces su estructura de tabla representa más o menos el modelo de datos de nuestro sistema + metadatos.

Sin embargo, otros miembros de mi equipo piensan que hoy en día es mejor simplemente serializar todo el gráfico de objetos en un archivo binario o XML.
No es necesario decir (pero aún lo diré) que la Tercera Guerra Mundial va entre nosotros y me gustaría escuchar su opinión sobre este tema.

Personalmente odio la serialización porque:

Los datos guardados se adhieren solo a su plataforma de desarrollo (C # en mi caso). Ninguna otra plataforma como Java o C ++ puede usar esta información.
Se guarda el gráfico completo de objetos (incluida toda la cadena de herencia) y no solo los datos que necesitamos.
Cambiar el modelo de datos puede causar graves problemas de compatibilidad con versiones anteriores al intentar cargar estados antiguos.
Compartir partes de los datos entre aplicaciones es problemático.

Me gustaría escuchar tu opinión sobre eso.

Consulte esta publicación de para obtener un comentario sobre la aplicabilidad de XML frente a la aplicabilidad de un sistema de gestión de bases de datos. Discute un problema que es bastante similar al tema del debate en su equipo.

Depende de lo que quieras serializar, por supuesto. En algunos casos, la serialización es ridículamente fácil.

(Una vez escribí un tipo de programa de línea de tiempo en Java, donde podías dibujar arrastrar y cambiar el tamaño de los objetos. Si estabas listo, podías guardarlo en un archivo (como myTimeline.til). En ese momenet, cientos de objetos estaban guardados, sus posición en el lienzo, su tamaño, sus colores, sus funciones internas, sus efectos especiales, ...

Por supuesto, podrías abrir myTimeLine.til y trabajar más.

Todo esto solo pedía algunas líneas de código . (acaba de hacer todas las clases y sus dependencias serializables) y mi tiempo de codificación tardó menos de 5 minutos, ¡estaba asombrado! (era la primera vez que usaba la serialización)

Al trabajar en una línea de tiempo, también puede ''guardar como'' para diferentes versiones y los archivos ''til'' donde es muy fácil hacer una copia de seguridad y enviar por correo.

Creo que en mi caso particular sería un poco idiota usar bases de datos. Pero eso es por supuesto solo para estructuras tipo documento, como Word para nombrar una).

Mi punto es lo primero: sin duda hay varios escenarios en los que las bases de datos no serían la mejor solución. La serialización no fue inventada por los desarrolladores solo porque estaban aburridos.

No es cierto si usa XMLserialization o SOAP
Ya no es del todo relevante
Solo si no tiene cuidado, hay muchas "mejores prácticas" para eso.
Solo si quiere que sea problemático, consulte 1

Por supuesto, la serialización tiene además de la velocidad de implementación otras ventajas importantes como no necesitar ninguna base de datos en algunos casos.

No dijo qué tipo de datos es, depende mucho de su rendimiento, simultaneidad, instalación, seguridad y disponibilidad / requisitos de centralización.

Si estos datos son muy grandes (por ejemplo, muchas instancias de los objetos en cuestión), una base de datos puede ayudar al rendimiento a través de sus capacidades de indexación. De lo contrario, probablemente perjudica el rendimiento o es indistinguible.
Si su aplicación está siendo ejecutada por varios usuarios simultáneamente, y es posible que quieran escribir estos datos, una base de datos ayuda porque puede confiar en las transacciones para garantizar la integridad de los datos. Con la persistencia basada en archivos, debe manejarlo usted mismo. Si los datos son de usuario único o instancia única, es muy probable que una base de datos sea excesiva.
Si su aplicación tiene su propia instalación de sopa a nueces, el uso de una base de datos supone una carga adicional para el usuario, quien debe configurar y mantener (aplicar parches, etc.) el servidor de la base de datos. Si se puede garantizar que la base de datos está disponible y es manejada por otra persona, esto no es un problema.
¿Cuáles son los requisitos de seguridad para los datos? Si los datos están centralizados, con múltiples usuarios (simultáneos o secuenciales), es posible que deba administrar la seguridad y los permisos sobre los datos. Sin ver los datos, es difícil decir si sería más fácil de administrar con persistencia basada en archivos o una base de datos.
Si los datos son solo locales, muchas de las preguntas anteriores sobre los datos tienen respuestas que apuntan hacia la persistencia basada en archivos. Si necesita acceso centralizado, las respuestas generalmente apuntan hacia una base de datos.

Supongo que probablemente no necesites una base de datos, basada únicamente en el hecho de que estás preguntando sobre ella, principalmente desde una perspectiva de conveniencia de programación y no desde una perspectiva de requisitos de datos. La serialización, especialmente en .NET, es altamente personalizable y se puede adaptar fácilmente para que persista solo las piezas esenciales que necesita. Existen buenas prácticas conocidas para versionar estos datos también, por lo que no estoy seguro de que haya una ventaja desde el punto de vista de la base de datos desde esa perspectiva.

Acerca de las preocupaciones de plataformas cruzadas: si no está seguro de que se requerirá una funcionalidad multiplataforma en el futuro, no la cree ahora. Es casi seguro que es más fácil resolver ese problema cuando llega el momento (migración, etc.) que restringir su desarrollo ahora. La mayoría de las veces, YAGNI .

Acerca de compartir datos entre partes de la aplicación: debe estar estructurado en la propia aplicación, por ejemplo, en las clases que acceden a los datos. No sobrecargue el mecanismo de persistencia para que también sea un conducto de datos entre las partes de la aplicación; si lo sobrecarga de esa manera, está convirtiendo el estado persistente en un contrato de objeto cruzado en lugar de tratarlo adecuadamente como una extensión del estado privado del objeto.

Para transferencia y almacenamiento fuera de línea, la serialización está bien; pero para uso activo, es preferible algún tipo de base de datos.

Típicamente (como dices), sin una base de datos, necesitas deserializar toda la secuencia para realizar cualquier consulta, lo que hace que sea difícil escalar. Agregue los problemas inherentes al roscado, etc., y está pidiendo dolor.

Algunos de sus otros puntos negativos acerca de la serialización no son todos ciertos, siempre y cuando elija sabiamente. Obviamente, BinaryFormatter es una mala elección para la portabilidad y el control de versiones , pero los " búferes de protocolo " (formato de serialización de Google) tienen versiones para Java, C ++, C# y muchos otros , y están diseñados para ser tolerantes a la versión.

Sí propagablemente cierto. La desventaja es que debe recuperar el objeto completo, que es como recuperar todas las filas de una tabla. Y si es grande, será un inconveniente. Pero si no es tan grande y con mis proyectos de hobby no lo son, ¿entonces deberían ser una pareja perfecta?

Solo asegúrese de tener un componente que maneje el estado de guardar / cargar con una interfaz limpia para el resto de su aplicación. Entonces, cualquiera que sea la elección que haga para la persistencia puede volver a visitarse fácilmente más adelante.

La serialización de un gráfico de objeto en un archivo puede ser una buena solución inicial rápida y sucia que es muy rápida de implementar.

Pero si comienza a encontrarse con problemas que hacen que una base de datos sea una mejor opción, puede conectar una nueva versión con poco o ningún impacto en el resto de la aplicación.

Tienes algunos puntos buenos. Estoy más o menos de acuerdo contigo, pero haré de abogado del diablo.

Bueno, siempre puedes escribir un convertidor en C # para extraer los datos más tarde si es necesario.
Ese es un punto débil, porque el espacio en disco es barato y la cantidad de bytes adicionales que utilizaremos cuesta mucho menos que el tiempo que desperdiciaremos tratando de hacer que todo funcione a su manera.
Esa es la manera del mundo. Grabe los puentes y requiera actualizaciones. Convierta los datos, o cree una herramienta para hacer eso, y luego deje de ser compatible con la forma de hacerlo de la versión anterior.
No si el programa C # transfiere los datos a las otras aplicaciones. Otras aplicaciones no deberían tener acceso a los datos que pertenecen a esta aplicación directamente, ¿verdad?