Persistencia de datos en Smalltalk/Seaside

Question

Últimamente he pasado algún tiempo conociendo Smalltalk and Seaside. Vengo del mundo de Java EE y, como pueden imaginar, ha sido un desafío ponerme a pensar en algunos de los conceptos de Smalltalk. :)

Por el momento estoy tratando de comprender cómo la persistencia de datos se implementa más comúnmente en el mundo Smalltalk. La suposición para mí como programador de Java es usar RDMS (es decir, MySQL) y ORM (es decir, Hibernate). Entiendo que este no es el caso de Smalltalk (utilizando al menos Hibernate). No necesariamente estoy buscando el método que se corresponda más con la forma en que se hace en Java EE.

¿Es más común guardar datos en la imagen, un almacén de objetos o RDMS? ¿Es incluso típico que las aplicaciones de Smalltalk usen RDMS?

Entiendo que no existe un enfoque único para todos y la estrategia de persistencia correcta dependerá de las necesidades de la aplicación (cuántos datos, concurrencia, etc.). ¿Cuál es un buen enfoque que puede comenzar simple pero también a escala?

He visto un video de Avi Bryant discutiendo la estrategia que utilizó para la persistencia y la escala DabbleDB. Por lo que entiendo, los datos del cliente se guardaron directamente en la imagen (una imagen por cliente). Eso funcionó en su caso de uso ya que los clientes no tenían que compartir datos. ¿Es este un enfoque común?

Espero que no haya hecho este TLDR. Muchas gracias a la visión que ustedes chicos de Smalltalk han proporcionado en mis preguntas anteriores. Es apreciado

Answer 1

Justin,

no se preocupe, Smalltalk no es tan diferente forma otros idiomas en esta área, ya que sólo añade la opción de persistencia basada en imágenes.

Hay mapeadores O/R como Hibernate para Smalltalk, GLORP y su puerto Pharo DBXtalk son sin duda los más populares en la actualidad. Estos deberían sentirse muy cómodos para ti si conoces a Hibernate.

Luego están las soluciones OODB como GemStone o Magma DB o VOSS y muchas otras que le permiten dejar atrás todos los problemas de mapeo O/R. La mayoría de estos están bastante limitados para almacenar objetos Smalltalk, siendo GemStone una excepción al proporcionar puentes a Ruby y otros idiomas.

También hay herramientas para almacenar objetos Smalltalk en bases de datos NoSQL modernas como CouchDB, Cassandra, GOODS u otras. El truco aquí es simplemente la conversión de valores de objeto Smalltalk a flujos JSON y un poco de solicitud HTTP.

Finalmente, existe la opción de guardar su imagen completa de Smalltalk. Diría que puede hacer eso en un entorno de producción, pero no es la forma estándar o preferida de dong para muchas personas. Lo haces mucho en desarrollo, porque puedes guardar una imagen y reanudar tu trabajo la próxima vez exactamente con todos los objetos en su lugar como los tuviste cuando guardaste.

Así que la línea base es: Todas las opciones de almacenamiento que usted conoce están disponibles también en Smalltalk, más una extra.

Joachim

Answer 2

supongo que básicamente depende del tamaño de su base de datos va a ser y qué tipo de carga que va a ser el manejo.

En mi caso, todas las aplicaciones que he escrito usan persistencia de imagen con serialización de disco. Básicamente, solo serializa tus objetos usando combustible a pedido.En mi caso, lo hago cada vez que se trata una información importante, más un proceso regular que los serializa cada 24 horas. La imagen también se guarda automáticamente cada 24 horas.

La aplicación más grande que escribí al usar este enfoque es manejar todos los procesos de negocios de una pequeña empresa de 10 trabajadores más alrededor de 50 trabajadores independientes que han estado usándola todos los días durante un año y medio. La carga de trabajo es bastante "grande" teniendo en cuenta que la aplicación trata con archivos grandes todo el tiempo, pero la aplicación se ha mantenido estable y rápida. Cambiar a un nuevo servidor y actualizar la imagen de Pharo fue tan fácil como recuperar el proyecto de Monticello y materializar la última "base de datos" serializada.

En mi opinión, ORM es un dolor innecesario, estamos en el mundo de los objetos, y tener que aplanar nuestros objetos parece estar mal, especialmente cuando tenemos buenas soluciones orientadas a objetos.

Por lo tanto, si su aplicación maneja cantidades bastante pequeñas de datos, le sugiero cualquiera de mi enfoque simple o SandstoneDB. Si su aplicación se ocupa de grandes cantidades de transacciones y datos, yo iría Gemstone.

Sólo mis dos centavos.

Answer 3

Ramon Leon describe la situación, las estrategias básicas y sus intercambios maravillosamente in his blog post.

Comenzaría con su marco de Persistencia de Imagen Simple, que I ported y uso en Pharo 1.3. Mariano Martinez Peck recientemente lo adaptó para usar Fuel (mismo enlace). Es muy simple, hace el trabajo y me da mucha más confianza para jugar a mi imagen, sabiendo que incluso si la daño permanentemente, todos mis datos estarán seguros. Copio las carpetas de datos a la nueva carpeta de imágenes, cargo mis paquetes y todos mis objetos están vivos en la nueva imagen.