我是Java用戶。最近，我需要爲MongoDB構建一個Web項目。根據軟件需求，我們必須頻繁改變採集結構，這意味着沒有永久性結構。在嘗試了MongoDB的幾個Java對象文檔映射器之後，如Morphia和MongoDB的彈簧數據，我發現這些框架不能支持集合結構的變化。我們事先在類中定義參數，但是如果更新後這些參數不再存在於集合中，或者某些新參數應該添加到類文件中？當收集結構變化很快時，Mongodb是否需要ORM？
我的問題是，當收集結構發生變化時，ORM是必需的。有沒有解決這種情況的方法？
這取決於你的意思是什麼，這些框架不支持集合結構的變化。如果您已經決定使用Java作爲您的開發語言，那麼您已經在某些方面承諾了相當嚴格的模式。您可以可以將您的業務類型建模爲地圖，然後您只需按名稱將地圖填入地圖中，而您並不在意類型或底層結構。至少在你將它們拉出並嘗試使用它們之前。您可以手動將您的Java對象轉換爲各種驅動程序類型（DBObject或Document），但這可能是一個相當不錯的工作，並且隨着事情的發展而出現錯誤。
Java只是強迫你考慮類型和結構的原因。隨着應用程序的演變從一種模式向下跳躍，Java的類型系統有助於找到您忘記更新代碼以匹配新結構的情況。任何一半體面的IDE都會幫助你重新構造這些新結構。
同樣，像Morphia或spring-data一樣使用和ODM將幫助您將數據導入和導出數據庫。根據您的開發週期的不同，您可能會使用舊模式在數據庫中存儲數據，但這與單獨使用ODM還是不同。實際上，使用ODM可以幫助您在代碼和應用程序中找到需要查看遷移到新模式的位置。
在數據庫級別，您需要在任何情況下進行遷移。這通常通過腳本來完成，你可以通過mongo shell來完成，但是可以通過Java和驅動程序完成。就是通過ODM使用實體類來遷移數據雖然不是不可能，但當然可能會很複雜，但這些問題與使用ODM或不使用ODM的決定基本上是正交的。
在構建了大量使用ODM（以及RDBMS系統上的ORM）的應用程序之後，我發現它們在演變架構時過度限制。最終令人頭疼的事情實際上是將數據按摩到新的形狀。使用ODM使業務代碼遷移到新模式幾乎微不足道。
最終，這是一個偏好問題，歸結爲您和您的團隊對此感到滿意。就個人而言，我更願意使用ODM，而不是依賴基於Map的業務實體或手動將數據傳入和傳出驅動程序。