天青/ AWS ORM設計指南

我設計和實現淨ORM必須支持Azure存儲（表，隊列，斑點）和AWS存儲（EBS，SimpleDB的，S3），並躲在一個通用的接口全部實現細節。主要的設計目標是簡單。天青/ AWS ORM設計指南

一些工作已在http://www.cs.virginia.edu/~humphrey/papers/CSAL.pdf中完成，但我認爲他們提出的接口與Azure/AWS存儲接口緊密耦合，如果添加新功能或舊功能被更改，可能會中斷。例如，我不在乎我可以創建/刪除表格，我只需要以最有效的方式存儲某種類型的對象。

所以，我想問問大家分享的準則表格關於這個問題的經驗（DO，考慮，避免不）。我真的很感謝任何從設計ORM的一般原則開始的洞察力，並且完成更精確的抽象層次，更可能持續考慮Azure和AWS最可能的演化路徑。

來源

2011-11-14 andriys

「更可能持續考慮Azure和AWS最可能的演化路徑」 - 人們怎麼可能知道這一點？ – millimoose

這是正確的，我們無法確定。最好的猜測就足夠了。 – andriys

如果你真的想避免緊耦合的，我建議你乾脆直接和最低組上可用的兩種類型的存儲功能之上的抽象層。

但無論如何，你正在試圖做的並沒有真正意義的我什麼。雲（非關係型）存儲非常奇怪，試圖構建通用ORM將是一個巨大的失敗。現代SQL ORMs是「好」的，因爲RDBMS都有一套共享的最小功能，實際上相當龐大，而且在大多數情況下你不需要特殊的東西。有了雲存儲，每個實現幾乎都是獨一無二的，正是因爲要牢記的第一個方面是可擴展性。例如，如果你在Azure中丟棄Blob租約，因爲在Amazon中它們不存在（我不知道，我只是做一個例子），那麼很可能你會很難管理Amazon中的blob併發訪問，在Azure也是如此，這沒有任何意義。

我寧願試圖實現的合理的設計，以避免在兩個平臺上的問題，但利用所有可用的功能（具有非常不同的實現方式，如果這是必要的）數據訪問層。

來源

2011-11-21 08:17:59

它確實對我有意義。我正在構建此API來解決[雲層之上：伯克利雲計算視圖]第2節中介紹的數據鎖定障礙/ Surge計劃機會（http://www.eecs.berkeley.edu/Pubs/TechRpts /2009/EECS-2009-28.pdf）。那麼，我是否正確地理解了你的建議：1.忘記構建通用的ORM，因爲它有99％的失敗概率。 2.爲Azure和AWS實施兩個不同的API，並使用每個API的完整功能集？ – andriys

是的，這就是我的意思。隔離接口後面的高級功能並實現兩個版本，每個版本都使用每個平臺的所有可用功能。如果只能針對2種存儲類型，那麼構建一個完整的ORM可能是過度的。 –

天青/ AWS ORM設計指南

回答

相關問題