Smalltalk / Seaside 中的数据持久化
我最近花了一些时间来熟悉 Smalltalk 和 Seaside。我来自 Java EE 世界，您可以想象，让我了解一些 Smalltalk 概念是一项挑战。 :)
目前我正在尝试了解数据持久性在 Smalltalk 世界中最典型的实现方式。作为一名 Java 程序员，我的假设是使用 RDMS（即 MySQL）和 ORM（即 Hibernate）。我知道 Smalltalk 的情况并非如此（至少使用 Hibernate）。我不一定要寻找最接近 Java EE 中完成方式的方法。
最常见的是将数据保存到映像、对象存储还是 RDMS 中吗？ Smalltalk 应用程序是否通常使用 RDMS？
我知道这里没有一刀切的方法，正确的持久性策略将取决于应用程序的需求（数据量、并发性等）。什么是既可以简单开始又可以扩展的好方法？
我观看了 Avi Bryant 讨论他用于持久性和扩展 DabbleDB 的策略的视频。据我了解，客户的数据直接保存到图像中（每个客户一张图像）。这在他的用例中很有效，因为客户不必共享数据。这是一种常见的方法吗？
希望我没有说出这个 TLDR。非常感谢 Smalltalk 人员在我之前的问题中提供的见解。值得赞赏。
I've been spending some time lately getting acquainted with Smalltalk and Seaside. I'm coming from the Java EE world and as you can imagine it's been challenging getting my mind around some of the Smalltalk concepts. :)
At the moment I'm trying to grasp how data persistence is most typically implemented in the Smalltalk world. The assumption for me as a Java programmer is to use RDMS (ie. MySQL) and ORM (ie. Hibernate). I understand that is not the case for Smalltalk (using Hibernate at least). I'm not necessarily seeking the method that maps most closely to the way it is done in Java EE.
Is it most common to save data into the image, an object store or RDMS? Is it even typical for Smalltalk apps to use RDMS?
I understand there is no one-size-fits-all approach here and the right persistence strategy will depend on the needs of the application (how much data, concurrency, etc). What's a good approach that can start simple but also scale?
I've watched a video of Avi Bryant discussing the strategy he used for persistence and scaling DabbleDB. From what I understand, the customer's data was saved right into the image (one image per customer). That worked in his use case since customers didn't have to share data. Is this a common approach?
Hope I didn't make this TLDR. Many thanks to the insight you Smalltalk guys have provided in my previous questions. It's appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Justin，
别担心，Smalltalk 在这方面与其他语言没有太大不同，它只是添加了基于图像的持久性选项。
有 O/R 映射器，例如 Hibernate for Smalltalk、GLORP 及其 Pharo 端口 DBXtalk 无疑是当今最受欢迎的。如果您了解 Hibernate，这些对您来说应该感觉非常舒服。
然后还有 OODB 解决方案，如 GemStone、Magma DB 或 VOSS 以及许多其他解决方案，让您摆脱所有 O/R 映射问题。其中大多数都仅限于存储 Smalltalk 对象，GemStone 是一个例外，它提供了与 Ruby 和其他语言的桥梁。
还有一些工具可以将 Smalltalk 对象存储在现代 NoSQL 数据库中，例如 CouchDB、Cassandra、GOODS 或其他数据库。这里的技巧只是将 Smalltalk 对象值转换为 JSON 流和一些 HTTP 请求。
最后，可以选择保存完整的 Smalltalk 图像。我想说你可以在生产环境中做到这一点，但这不是许多人的标准或首选方式。您在开发过程中经常这样做，因为您可以简单地保存图像并在下次继续工作，所有对象都处于保存时的位置。
所以底线是：您所知道的所有存储选项在 Smalltalk 中都可用，另外还有一个。
约阿希姆
Justin,
don't worry, Smalltalk is not so different form other languages in this area, it just adds the Image based persistence option.
There are O/R mappers like Hibernate for Smalltalk, the GLORP and its Pharo port DBXtalk are surely the most popular ones these days. These should feel very comfortable for you if you know Hibernate.
Then there are OODB solutions like GemStone or Magma DB or VOSS and many others that let you leave all the O/R-mapping problems behind. Most of these are pretty limited to storing Smalltalk objects, GemStone being an exception in providing bridges to Ruby and other languages.
There also are tools to store Smalltalk objects in modern NoSQL databases like CouchDB, Cassandra, GOODS or others. The trick here is just the conversion of Smalltalk object values to JSON streams and a little HTTP-requesting.
Finally there is the option of saving your complete Smalltalk image. I'd say you can do that in a production environment, but it's not the standard or preferred way of dong it for many people. You do it a lot in development, because you can simply save an image and resume your work the next time exactly with all objects in place as you had them when you saved.
So the base line is: All the storage options you know are available in Smalltalk as well, plus one extra.
Joachim
我想这基本上取决于您的数据库有多大以及它将处理什么样的负载。
就我而言，我编写的所有应用程序都使用图像持久性和磁盘序列化。本质上，您只需根据请求使用 Fuel 来序列化您的对象。就我而言，每次处理重要数据时我都会这样做，并定期进行每 24 小时序列化一次的过程。该图像还每 24 小时自动保存一次。
我使用这种方法编写的最大的应用程序是处理一家由 10 名员工和大约 50 名自由职业者组成的小公司的所有业务流程，这些人一年半以来每天都在使用它。考虑到应用程序始终处理大文件，工作量相当“大”，但应用程序保持稳定和快速。切换到新服务器并更新 Pharo 映像就像从 monticello 取回项目并实现最新的序列化“数据库”一样简单。
在我看来，ORM 是一种不必要的痛苦，我们处于对象世界中，必须扁平化我们的对象感觉是错误的，尤其是当我们有很好的面向对象解决方案时。
因此，如果您的应用程序处理相当少量的数据，我建议使用我的简单方法或 SandstoneDB。如果您的应用程序处理大量交易和数据，我会选择 Gemstone。
只是我的两分钱。
I guess it basically depends on how big your DB is going to be and what kind of load will it be handling.
In my case, all apps I ever wrote use image persistance with disk serialization. Essentially, you just serialize your objects by using Fuel at request. In my case, I do so every time an important piece of data is dealt with, plus a regular process that serializes them every 24 hours. The image is also automatically saved every 24 hours.
The biggest application I wrote by using this approach is handling all the business processes of a small company of 10 workers plus around 50 freelancers who have been using it every day for a year and a half. The workload is pretty "big" taking in account the application deals with big files all the time, but the app has stayed stable and fast. Switching to a new server and updating the Pharo image was as easy as getting the project back from monticello and materializing the latest serialized "database".
In my opinion, ORM is an unnecessary pain, we're in the object world, and having to flatten our objects feels just wrong, especially when we have nice object-oriented solutions.
So, if your app handles fairly small amounts of data, I'd suggest either my simple approach or SandstoneDB. If your app deals with huge amounts of transactions and data, I'd go Gemstone.
Just my two cents.
Ramon Leon 在他的博文中精美地描述了情况、基本策略及其权衡。
我将从他的基于简单图像的持久性框架开始，我移植并在 Pharo 1.3 中使用该框架。马里亚诺·马丁内斯·佩克 (Mariano Martinez Peck) 最近对其进行了修改，以使用 Fuel（同一链接）。它非常简单，可以完成工作，并且让我更有信心发挥我的形象，因为我知道即使我永久损坏它，我的所有数据都是安全的。我只需将数据文件夹复制到新的图像文件夹，加载我的包，并且我的所有对象都在新图像中存在。
Ramon Leon describes the situation, basic strategies, and their tradeoffs beautifully in his blog post.
I would start with his Simple Image Based Persistence framework, which I ported and use in Pharo 1.3. Mariano Martinez Peck recently adapted it to use Fuel (same link). It's very simple, does the job, and gives me much more confidence to play in my image, knowing that even if I permanently damage it, all my data is safe. I just copy the data folders to the new image folder, load my packages, and all my objects are alive in the new image.