persistence - Persistencia de datos en Smalltalk/Seaside
(3)
Últimamente he estado pasando un tiempo familiarizándome con Smalltalk y Seaside. Vengo del mundo de Java EE y, como pueden imaginar, ha sido un desafío lograr que mi mente aborde algunos de los conceptos de Smalltalk. :)
En este momento, estoy tratando de comprender cómo la persistencia de datos se implementa más típicamente en el mundo de Smalltalk. El supuesto para mí como programador de Java es utilizar RDMS (es decir, MySQL) y ORM (es decir, Hibernate). Entiendo que no es el caso de Smalltalk (al menos con Hibernate). No necesariamente estoy buscando el método que se relaciona más estrechamente con la forma en que se realiza 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 Smalltalk usen RDMS?
Entiendo que no existe un enfoque único para todos los casos y que la estrategia de persistencia correcta dependerá de las necesidades de la aplicación (la cantidad de datos, la concurrencia, etc.). ¿Cuál es un buen enfoque que puede comenzar simple pero también escalar?
He visto un video de Avi Bryant discutiendo la estrategia que usó para la persistencia y escalando DabbleDB. Según tengo entendido, 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 no haber hecho este TLDR. Muchas gracias a la información que ustedes, chicos de Smalltalk, han brindado en mis preguntas anteriores. Es apreciado
Justin
no se preocupe, Smalltalk no es tan diferente de otros idiomas en esta área, solo agrega la opción de persistencia basada en imágenes.
Hay mapeadores O / R como Hibernate para Smalltalk, el GLORP y su puerto Pharo DBXtalk son seguramente los más populares en estos días. Estos deben sentirse muy cómodos para ti si conoces 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 O / R-mapping. La mayoría de estos están bastante limitados al almacenamiento de objetos Smalltalk, y GemStone es una excepción para proporcionar puentes a Ruby y otros idiomas.
También hay herramientas para almacenar objetos Smalltalk en bases de datos modernas NoSQL como CouchDB, Cassandra, GOODS u otros. El truco aquí es simplemente la conversión de los valores de los objetos Smalltalk a flujos JSON y un poco de solicitud HTTP.
Finalmente, existe la opción de guardar su imagen completa de Smalltalk. Yo diría que puedes hacer eso en un entorno de producción, pero no es la forma estándar o preferida de hacerlo para muchas personas. Lo haces mucho en desarrollo, porque simplemente puedes guardar una imagen y reanudar tu trabajo la próxima vez exactamente con todos los objetos en su lugar como los tenías cuando los guardaste.
Entonces, la línea de base es: Todas las opciones de almacenamiento que conoce también están disponibles en Smalltalk, más una extra.
Joachim
Ramon Leon describe a la perfección la situación, las estrategias básicas y sus compensaciones en su blog .
Comenzaría con su marco de Persistencia Basada en Imágenes Simples, que ported y uso en Pharo 1.3. Mariano Martínez Peck lo adaptó recientemente para usar Combustible (mismo enlace). Es muy simple, hace el trabajo y me da mucha más confianza para jugar con mi imagen, sabiendo que aunque la dañe permanentemente, todos mis datos están a salvo. Simplemente 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.
Supongo que básicamente depende de qué tan grande va a ser su base de datos y qué tipo de carga va a manejar.
En mi caso, todas las aplicaciones que escribí utilizan la persistencia de la imagen con la serialización del disco. Esencialmente, simplemente serializa tus objetos usando Fuel a pedido. En mi caso, lo hago cada vez que se trata un dato 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 importante que escribí utilizando este enfoque es el manejo de todos los procesos de negocios de una pequeña empresa de 10 trabajadores más unos 50 freelancers que lo han estado utilizando todos los días durante un año y medio. La carga de trabajo es bastante "grande" teniendo en cuenta que la aplicación se ocupa de 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, el ORM es un dolor innecesario, estamos en el mundo de los objetos y tener que aplanar nuestros objetos se siente mal, especialmente cuando tenemos buenas soluciones orientadas a objetos.
Por lo tanto, si su aplicación maneja cantidades bastante pequeñas de datos, sugeriría mi enfoque simple o SandstoneDB. Si su aplicación trata con grandes cantidades de transacciones y datos, me gustaría ir a Gemstone.
Sólo mis dos centavos.