Linee guida per la progettazione ORM di Azure/AWS

Question

Sto progettando e implementando ORM .NET che deve supportare sia Archiviazione di Azure (tabelle, code, BLOB) e Archiviazione AWS (EBS, SimpleDB, S3) e nascondere tutti i dettagli di implementazione dietro un'interfaccia comune . L'obiettivo principale del design è la semplicità.

Alcuni dei lavori sono stati eseguiti in http://www.cs.virginia.edu/~humphrey/papers/CSAL.pdf, ma la loro interfaccia proposta è, a mio parere, troppo stretta con l'interfaccia di archiviazione Azure/AWS ed è probabile che si interrompa in caso di aggiunta di nuove funzionalità o di modifiche precedenti. Ad esempio, non mi interessa che io possa creare/eliminare tabelle, ho solo bisogno di memorizzare un oggetto di qualche tipo in un modo più efficiente.

Quindi, vorrei chiederti di condividere la tua esperienza sull'argomento sotto forma di linee guida (DO, CONSIDER, EVITARE, NON). Gradirei davvero qualsiasi intuizione iniziando con i principi generali di progettazione di ORM e terminando con il livello preciso di astrazione che è più probabile che duri considerando i percorsi di evoluzione più probabili di Azure e AWS.

Answer 1

Se si vuole davvero evitare l'accoppiamento stretto, suggerisco di implementare semplicemente e il livello di astrazione in cima al set minimo di funzionalità disponibili su entrambi i tipi di storage.

Ma in ogni caso, quello che stai cercando di fare non ha senso per me. Lo storage cloud (non relazionale) è così peculiare che provare a costruire un ORM generico sarà un enorme fallimento. I moderni ORM SQL sono "buoni" perché gli RDBMS hanno tutti un set minimo condiviso di funzionalità che è in realtà piuttosto vasto e nella maggior parte dei casi non è necessario il materiale esotico. Con lo storage cloud, ogni implementazione è quasi unica, proprio perché il primo aspetto da tenere a mente è la scalabilità. Ad esempio, se butti via i lease di Blob in Azure perché in Amazon non esistono (non ho idea, sto solo facendo un esempio), quindi probabilmente avresti difficoltà a gestire l'accesso simultaneo di blob in Amazon e anche in Azure, e questo non ha senso.

Preferirei provare a implementare un livello di accesso ai dati progettato in modo ragionevole per evitare problemi, ma sfruttare TUTTE le funzionalità disponibili in entrambe le piattaforme (con implementazioni molto diverse se necessario).