Azure/AWS ORMデザインガイドライン

Question

Azure Storage（テーブル、キュー、BLOB）とAWSストレージ（EBS、SimpleDB、S3）の両方をサポートする必要がある.Net ORMを設計して実装しています。 。主な設計目標はシンプルさです。

一部の作業はhttp://www.cs.virginia.edu/~humphrey/papers/CSAL.pdfで行われていますが、私の意見では、Azure/AWS Storageインターフェイスと密接に結びついていて、新しい機能が追加されたり、古い機能が変更された場合は破損する可能性があります。例えば、私はテーブルを作成/削除することはできませんが、最も効率的な方法である種のオブジェクトを保存するだけで済みます。

私はあなたの経験をガイドラインの形で（DO、CONSIDER、AVOID、DO NOT）の形で共有するようお願いします。 AzureとAWSの最も可能性の高い進化の経路を考え続ける可能性が高い、抽象度の高い正確なレベルでORMを設計し、仕上げるという一般原則から始めて、私は本当に感謝しています。

Answer 1

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

しかし、とにかく、あなたがやろうとしていることは本当に私にとっては意味がありません。クラウド（非リレーショナル）ストレージは非常に独特で、一般的なORMを構築しようとすると巨大な失敗に終わります。現代のSQL ORMは、RDBMSに共通の最小セットの機能があり、実際には非常に広大で、ほとんどの場合、異質なものは必要ないため、「良い」ものです。クラウドストレージでは、それぞれの実装はほぼ独特です。なぜなら、最初の側面はスケーラビリティだからです。たとえば、AmazonでAmazonが存在しないため、BlobリースをAzureに捨てると（私は考えていません）、AmazonでBlob並行アクセスを管理するのは難しいでしょう。アズールでも、それは理にかなっていません。

私はむしろ、問題を避けるためにはっきりと設計されていますが、両方のプラットフォームで利用可能なすべての機能を活用するように設計されたデータアクセス層を実装しようとします。