6

Azure Storage（テーブル、キュー、BLOB）とAWS Storage（EBS、SimpleDB、S3）の両方をサポートし、すべての実装の詳細を共通のインターフェイスの背後に隠す必要がある.NetORMを設計および実装しています。主な設計目標は単純さです。

一部の作業はhttp://www.cs.virginia.edu/~humphrey/papers/CSAL.pdfで行われていますが、提案されたインターフェイスは、私の意見では、Azure / AWSストレージインターフェイスと緊密に結合されており、新しい機能が追加されたり、古い機能が変更されたりすると、破損する可能性があります。たとえば、テーブルを作成/削除できるかどうかは気にせず、最も効率的な方法で特定のタイプのオブジェクトを格納するだけで済みます。

それで、私はあなたにガイドラインの形で主題に関するあなたの経験を共有するようにお願いしたいと思います（する、考慮する、避ける、しないでください）。ORMの設計の一般原則から始まり、AzureとAWSの最も可能性の高い進化パスを考慮して持続する可能性が高い正確なレベルの抽象化で終わる洞察を本当にいただければ幸いです。

4

1 に答える 1

1

密結合を本当に避けたい場合は、両方のタイプのストレージで使用できる最小限の機能セットの上に、単純に実装して抽象化レイヤーを作成することをお勧めします。

しかしとにかく、あなたがやろうとしていることは私には本当に意味がありません。クラウド（非リレーショナル）ストレージは非常に特殊であるため、汎用ORMを構築しようとすると大きな失敗になります。最新のSQLORMは「優れた」ものです。これは、RDBMSにはすべて、実際には非常に膨大な機能の共有最小セットがあり、ほとんどの場合、エキゾチックなものは必要ないためです。クラウドストレージでは、各実装はほぼ一意です。これは、最初に覚えておくべき側面がスケーラビリティであるためです。たとえば、AmazonにBlobリースが存在しないためにAzureでBlobリースを破棄した場合（私にはわかりませんが、例を示しているだけです）、AmazonとAzureでも、それは意味がありません。

問題を回避するために賢明に設計されたデータアクセス層を実装しようとしますが、両方のプラットフォームで利用可能なすべての機能を活用します（必要に応じて非常に異なる実装を使用します）。

于 2011-11-21T08:17:59.673 に答える