2011-03-03 49 views
7

我們有一個在三個應用程序中使用的對象模型。兩個程序收集數據,另一個讀取數據並生成報告。這個系統非常不連貫,所以我們不能有一個單一的數據庫,所有的程序都可以對話。我想要一個ORM嗎?

現在,程序只是使用公共庫來填充對象模型並序列化/反序列化到磁盤。具體來說,我們正在使用XML序列化。

這個模型有幾個問題。 1)XML可能被認爲是浪費。這些文件可能變得龐大而笨拙。老實說,文件大小現在不是一個大問題。 2)我最關心的是記憶足跡。整個文件被加載到一個對象模型中,對其進行操作,然後保存。

希望我已經表達了我的擔心,在某些時候,我們會在運行時遇到有關此應用程序的內存問題。足夠的數據將被收集到一個「數據庫」(xml文件),它不能一次加載到內存中。

我想要的是訪問我的對象模型支持文件存儲而不是內存。我希望對象模型的更改最小化。當一個對象被訪問時,它來自磁盤,當它被設置時,它會被保存(如果可能,會自動保存)。

我們用SQLite,SQL Compact 4.0和EF 4以及LINQ to XML(簡要地)研究了NHibernate。過去我也使用db4o將對象緩存到磁盤,但那是一個無關的項目。

在我潛入並花時間學習其中之一之前,我想知道我的想法是否有意義。我可以有一個對象模型「神奇地」緩存到存儲介質,而不是無限地膨脹我的內存足跡?即使它不是最優雅的,完成這件事的最短路徑是什麼?

是否有其他技術可以幫助我?內存映射文件,linq-to-sql,Lazy(T)(僅在需要時才從文件中獲取對象)。

我意識到這是一個開放式問題。我正在尋找一個大的圖片響應和細節,如果有人在那裏有真實世界的經驗這樣做。鏈接將有幫助...

謝謝。

+0

您是否因爲使用移動設備而有內存問題?我問,因爲我看到sql-server-ce作爲標籤。 – 2011-03-03 08:08:23

+0

現在不能移動,看着SQL Server Compact,因爲它可以嵌入到我的應用程序中(比如SQLite)。如果我們使用EF,SQL Compact將成爲數據庫後端的考慮因素。內存方面的擔憂是由於它是一款32位應用程序,因此2GB的處理限制。 – Nate 2011-03-03 08:12:22

+0

您的應用是獨立應用嗎?這聽起來像你不想要一個集中的數據庫。該應用是否爲多用戶?你多久更新一次?對應用程序做了多少報告?這些是您選擇時重要的問題類型。 – Andrew 2011-03-03 08:31:41

回答

4

我剛剛完成將一個(通常是「繼承的」)由XML文件支持的Web應用程序遷移到NHibernate,完全出於同樣的考慮。我也處於以前從未使用NHibernate並希望在此過程中學習的相同情況。 這個想法確實有道理。你確實能夠在內存中加載你實際需要的部分(而不是整個數據庫)以及更多的好處。

基於您要求的其他事情(對象模型的最小更改,可輕鬆從實際遷移到基於ORM的應用程序)我不確定您會如此輕鬆地獲得它們。 對於像NHibernate和EF4這樣的ORM,模型類非常輕便:它們基本上只比屬性容器更多。基於XML文件的應用程序往往直接在模型中使用更多的邏輯:您可能必須轉移到數據訪問層的邏輯。重新設計模型和數據訪問層可能是您將面臨的最耗時的任務。我知道這是給我的。

我從你的問題推斷出的另一件事(你說你不能讓所有的三個程序都與同一個數據庫對話,而你提到SQLite和SQL Compact)就是你正在通過複製你的三個應用程序來複制你的數據身體文件。你如何檢測到變化以及你需要3個DB如何對齊?您目前如何合併更改(如果您有3個應用程序中的2個可以寫入數據)? 根據您複製數據的方式,這是ORM可能或不可以幫助您的事情。

編輯根據您的意見

  • 如果你想在一個點上的文件合併到一個數據庫和您還不相信這將是微軟的產品,然後NHibernate的是一些積分最佳選擇。但是,如果您現在正在廣泛使用LINQ(根據您的其他評論)並希望進行更加無縫的轉換,那麼我將使用EF4:Nhibernate.Linq並非真正完整,某些構造不起作用。
  • NHibernate和EF4都有很好的文檔記錄,並且有非常好的教程,介紹如何從頭開始構建完整的應用程序,因此學習部分非常簡單。
  • 兩者都有一個「模型第一」的方法,您可以根據您的模型類獲得一個爲您創建數據庫的工具,因此如果您的模型類非常輕量級,則應該可以稍加修改地使用它們。
  • 在NHibernate中花費了我一些時間(並且仍然有時候很難讓我工作)的事情是配置級聯以符合我的預期:刪除對象時「相關」對象會發生什麼?
+0

感謝您分享這些信息。我的對象模型目前非常輕量級。每個對象只是一些屬性,其中有一些更改的數據綁定事件...所以EF或NHibernate可能是適當的。我擔心學習過程需要多長時間。這兩種產品看起來都很複雜。就合併而言,我現在並不擔心它。目前,我們一次只能處理一個文件。明年可能會將文件合併到中央數據庫中。我們已經努力使對象在文件間唯一標識。 – Nate 2011-03-03 15:54:12

+0

@Nate:而不是在評論中回答我直接編輯我的答案(太長的評論...)。希望能幫助到你。 – 2011-03-04 07:14:30

+0

非常感謝您的額外信息。我正在深入挖掘NH和EF。我發現自己對EF的興趣不大。設置看起來很複雜。 – Nate 2011-03-05 08:19:38

6

是的,ORM將一個對象模型映射到關係模型。他們在隱藏讀寫數據到數據庫,緩存數據,管理內存等所有管道工作方面做得非常好。他們還能夠緩存對象圖的一部分,並且可以做一些事情來提高性能如延遲加載數據。

+0

謝謝,聽起來我正走向一條好路。 – Nate 2011-03-03 15:55:02

1

我的建議是你使用文檔數據庫。 RavenDB會給你很多好處。您將能夠存儲這些對象,而無需將它們轉換爲關係模型,就像db4o會做的那樣。

但是,使用RavenDB您可以使用Map/Reduce查詢數據。另一個好處是,它是使用.NET for .NET編寫的,所以您會喜歡在Linq中查詢。它可以作爲Windows服務或IIS運行。它也可以運行嵌入式,這對於測試目的非常有用。這對您的數據收集應用程序可能是一個好主意。

RavenDB還支持複製,以便您可以將數據存儲在一個實例中並將其複製到另一個實例中。也許這可以解決你的分佈式設置。

但是,根據分佈式設置的性質,我認爲使用服務總線會更好。數據收集應用程序中是否需要狀態?如果沒有,只需在服務總線上發佈一條包含數據的消息,以供系統的另一部分使用。聽起來很複雜,但實際上並非如此。看看nServicebus

+0

RavenDB聽起來很有趣。我喜歡這種格式是JSON。我被db4o的許可模式關閉了。他們想要每個應用程序的合同,成本很高。這似乎更合理。我可能會研究它。至於nServicebus,這聽起來也很有趣,也許我們會在明年展望。目前,使用運動鞋的網絡複製文件。機器在地理上與任何網絡分離並斷開連接。明年我可能不得不將某些「上傳者」放在一起,以便在機器回到「母艦」時使用。 – Nate 2011-03-03 15:59:55