2009-09-10 72 views
1

我正在使用以下代碼將對象及其所有屬性保存到數據庫。它使我無需在每個業務對象中創建保存方法。在我的基類中的代碼是:可以使用反射來獲取基類中的屬性名稱和值嗎?

public void Save() 
    { 
     List<SqlParameter> Params = new List<SqlParameter>(); 
     foreach (PropertyInfo Property in this.GetType().GetProperties()) 
     { 
      if (Property.CanRead)     
       Params.Add(new SqlParameter(Property.Name,Property.GetValue(this,null)));     
     } 
     Execute<int>(SaveProcedure, Params.ToArray());   
    } 

這是一個很好的做法還是我將關閉不使用反射和創建中的每個對象創建一個保存方法更好呢?

任何其他想法或建議表示讚賞,謝謝!

+0

如果您的數據庫沒有與您的對象的屬性名稱匹配的字段,則可能會遇到一些問題。 – Frinavale 2009-09-10 18:55:59

+0

謝謝大家的快速回復。我將研究LinqToSql並徹底擺脫它。 – Mike 2009-09-10 19:21:51

回答

7

看起來你正在創建自己的基本ORM。您是否考慮過使用專門爲.NET框架編寫的任何完全成熟的映射器來執行此任務,例如LinqToSql或?

0

作爲一個工作嚴重依賴反思的人,我認爲這不合適。不過,你應該仔細考慮它的權衡。使用反射選項你從編譯時間檢查,這意味着沒有及早的錯誤檢測。所以如果你真的認爲反射可以幫助你更好地管理代碼,並且你不介意它的性能,那麼使用反射不應該是一個問題。

另一個說明,每次使用反射時,都會確保您創建足夠的測試以幫助您儘早發現問題。

只是一個雖然。

0

反射實際上僅用於程序分析。使用它對你的程序的性能和可證性有非常嚴重的副作用。這並不意味着在生產應用中沒有反射適用的情況,但我不認爲這是這種情況之一。爲了存儲在數據庫中,我建議查找序列化。

0

從設計的角度來看,我認爲每個班級都有一個單獨的保存更加靈活。這將允許選擇相同的屬性,並允許在存儲到數據庫之前進行必要的預處理(即,複雜的對象本身不能保存)。

1

我通常會將這種情況歸類爲不良或至少是差的做法。反射成本來自幾個角度,其中最高的成本是調用(即調用方法,獲取或設置屬性/字段值等)。通過像這樣反射來保存對象,您的成本非常高。數量級比直接訪問屬性慢幾個數量級

拋開反射成本,從意圖的角度來看,這通常也是一種不好的做法,你要保存所有的屬性......但是當有人創建一個具有屬性的派生類型時會發生什麼不要映射到廣告數據庫表列?您應該使您的保存方法變爲虛擬或抽象,並根據每個實體的需要實施/擴展該方法。

最後一點......直接在像這樣的實體上處理保存是一個真正的維護夢魘,只是等待發生。當你將擔憂和責任融合到一個班級中時,你需要一個很大的麻煩。你會更好地使你的實體/業務對象POCO(普通的舊的clr對象)和寫明確的數據映射器。這將分離您的擔憂,並儘可能減少每個班級的責任。豐富的自我保存(和裝載)實體很方便,但主要是一個夢想。在實踐中,鑑於您將面臨更大的維護困難,他們通常不值得他們提供的小好處。

我建議查看OR映射器(LINQ to SQL,nHibernate,Entity Framework v4等)。)OR映射器在您需要加載,保存或刪除實體時自動爲您生成SQL。當您不使用OR映射器時,它們可以消除大量額外的編碼,並且支持更具適應性的代碼庫。

相關問題