2009-02-18 32 views
1

一個有趣的問題出現在twitter今晚,我想我會在這裏發佈。您的代碼庫的百分比是由數據訪問代碼表示的?

基本上,我想知道你用什麼來保存數據到你的數據庫和估計你的代碼庫的百分比是數據訪問代碼。

- 編輯 -
其他有趣的指標(如註釋中所述)包括業務類別的數量和代碼庫的總體大小。

我剛看了一個項目,發現NHibernate之前做了很長時間。快速查看一些數據訪問代碼,可以看出約10行代碼用於持久性/水合性,以表示類中的每個持久性屬性。

+0

我猜生成的代碼不算?另外,大約「商業類」或總代碼大小可能會對攤銷效應產生影響。 – 2009-02-18 06:51:59

+0

哦,是的。生成的代碼最重要。儘管生產時間不會很長,但在某些時候會有維護。 – RKitson 2009-02-18 06:55:10

回答

1

在一個項目中,我們使用了LLBLGenPro作爲我們的OR/M。但是因爲我們不想用LLBL實體來處理我們的應用程序,所以我們在將它們映射到我們的BO之前將它們映射到客戶端。這意味着在再次敲擊數據庫之前將它們映射回LLBL實體。 DAL代碼最終成爲我們應用程序的一大部分。不是50%,但很大。

在我現在工作的一個項目中,我開始使用db40,希望將DAL佔用空間降至最低。它非常小,但我遇到了db40的問題,不得不放棄它。爲了得到一些工作,我轉向ADO.NET幾天,並驚訝於爲了獲得簡單的存儲庫而需要編寫多少個ADO。這很令人頭疼,所以我最終選擇了NHibernate。

我與NHibernate(2.0)的DAL代碼可能是我的代碼基數的5%或更少。這包括XML映射文件。我的意思是,DAL足跡非常小,並且很樂意與之合作。在過去的分佈式環境中,我需要使用分離對象來處理NHibernate 1.2,但NHibernate 2.0似乎解決了這個問題。我知道這是我從現在開始做DAL的方式,直到有更好的事情出現。

有趣的是,我和我的同事幾個月前也有類似的對話。但我們的重點不在於我們的DAL佔多少代碼,而是我們的應用程序中有多少是簡單的數據查詢/操作。我們估計大概90%的應用程序只是提取正確的數據子集並允許用戶進行編輯。

0

大多數時候我們使用nHibernate,它是由一個工具生成的,不知道如果重要的話,我們最終還是會爲每個實體添加大量的代碼到nHibernate層,並且是;它確實成爲代碼的一大部分。

此外,隨着您在應用中添加更多功能和更多實體,DAL代碼也會增加。 或多或少,我猜想20%-30%左右的代碼庫是由DAL組成的。