20

私は最近、Smalltalk と Seaside に慣れるために時間を費やしています。私は Java EE の世界から来ましたが、ご想像のとおり、Smalltalk の概念のいくつかを理解するのは大変でした。:)

現在、データの永続性が Smalltalk の世界で最も一般的にどのように実装されているかを理解しようとしています。Java プログラマーとしての私にとっての前提は、RDMS (つまり MySQL) と ORM (つまり Hibernate) を使用することです。Smalltalk (少なくとも Hibernate を使用) には当てはまらないことを理解しています。Java EE で行われている方法に最も近い方法を必ずしも探しているわけではありません。

データをイメージ、オブジェクト ストア、RDMS のいずれに保存するのが最も一般的ですか? Smalltalk アプリが RDMS を使用するのは一般的ですか?

ここには万能のアプローチはなく、適切な永続化戦略はアプリケーションのニーズ (データ量、同時実行性など) によって異なることを理解しています。シンプルに始めて拡張できる良いアプローチは何ですか?

Avi Bryant が永続化と DabbleDB のスケーリングに使用した戦略について話しているビデオを見たことがあります。私が理解していることから、顧客のデータは画像に直接保存されていました (顧客ごとに 1 つの画像)。顧客はデータを共有する必要がないため、彼のユースケースではうまくいきました。これは一般的なアプローチですか？

このTLDRを作成していないことを願っています。以前の質問で Smalltalk の皆さんが提供してくれた洞察に感謝します。感謝しています。

4

3 に答える 3

13

ジャスティン、

心配しないでください。Smalltalk は、この分野の他の言語とそれほど違いはありません。イメージ ベースの永続化オプションが追加されているだけです。

Hibernate for Smalltalk のような O/R マッパーがあり、GLORP とその Pharo ポート DBXtalk は、最近最も人気のあるものです。Hibernate を知っている場合、これらは非常に快適に感じるはずです。

次に、GemStone、Magma DB、VOSS などの OODB ソリューションや、O/R マッピングの問題をすべて解決できる他の多くのソリューションがあります。これらのほとんどは Smalltalk オブジェクトの格納にかなり限定されており、GemStone は Ruby や他の言語へのブリッジを提供する例外です。

CouchDB、Cassandra、GOODS などの最新の NoSQL データベースに Smalltalk オブジェクトを格納するツールもあります。ここでの秘訣は、Smalltalk オブジェクトの値を JSON ストリームに変換し、HTTP 要求を少し行うだけです。

最後に、完全な Smalltalk イメージを保存するオプションがあります。実稼働環境でそれを行うことができると思いますが、多くの人にとって、それは標準的または推奨される方法ではありません。画像を保存するだけで、次回は保存したときと同じようにすべてのオブジェクトを正確に配置して作業を再開できるため、開発中に多くのことを行います。

したがって、ベース ラインは次のとおりです。ご存知のすべてのストレージ オプションは、Smalltalk でも利用できます。

ヨアヒム

于 2011-12-01T15:34:57.183 に答える
9

それは基本的に、DB のサイズと処理する負荷の種類に依存すると思います。

私の場合、これまでに作成したすべてのアプリで、ディスクのシリアル化によるイメージの永続化を使用しています。基本的に、要求に応じて Fuel を使用してオブジェクトをシリアル化するだけです。私の場合、重要なデータが処理されるたびに、さらに 24 時間ごとにそれらをシリアル化する通常のプロセスでこれを行います。画像も24時間ごとに自動保存されます。

このアプローチを使用して作成した最大のアプリケーションは、1 年半毎日使用している 10 人の従業員と約 50 人のフリーランサーからなる小さな会社のすべてのビジネス プロセスを処理することです。アプリケーションが常に大きなファイルを処理することを考慮すると、ワークロードはかなり「大きい」ですが、アプリは安定して高速に保たれています。新しいサーバーに切り替えて Pharo イメージを更新することは、モンティチェロからプロジェクトを取り戻し、最新のシリアル化された「データベース」を具体化するのと同じくらい簡単でした。

私の意見では、ORM は不必要な苦痛です。私たちはオブジェクトの世界にいるので、オブジェクトをフラット化する必要があるのは、特に優れたオブジェクト指向ソリューションがある場合は、まったく間違っていると感じます。

したがって、アプリが処理するデータ量がかなり少ない場合は、私の単純なアプローチか SandstoneDB のいずれかをお勧めします。あなたのアプリが膨大な量のトランザクションとデータを扱うなら、Gemstone を選びます。

ちょうど私の2セント。

于 2011-12-01T16:20:21.527 に答える
7

Ramon Leon は、彼のブログ投稿で、状況、基本的な戦略、およびそれらのトレードオフを美しく説明しています。

私は彼の Simple Image Based Persistence フレームワークから始めます。これを移植して Pharo 1.3 で使用しました。Mariano Martinez Peck は最近、Fuel を使用するように調整しました (同じリンク)。それは非常に簡単で、仕事をし、自分のイメージでプレイする自信を与えてくれます.永久に損傷したとしても、すべてのデータは安全であることを知っています. データ フォルダーを新しいイメージ フォルダーにコピーし、パッケージをロードするだけで、すべてのオブジェクトが新しいイメージで有効になります。

于 2011-12-01T18:14:53.423 に答える