2011-07-14 21 views
4

爲了保護我們自己免於因爲任何屬性重命名而失敗(假設您重新生成了您的poco類,因爲您已經更改了相關Db表中的某些列名),對於保留屬性名稱的常量字符串內?在公共常量字符串中存儲私有名稱是一種很好的做法嗎?

public const string StudentCountPropertyName = "StudentCount"; 
public int StudentCount {get;set;} 

例如:考慮DataBinding;顯式地在DataFieldName屬性中鍵入屬性名稱。

或者這不是一個好主意,有更好更安全的方法嗎?

+3

你如何提出利用這些常量的存在? –

+0

想象一下:DataFieldName =「<%= StudentCollection.StudentCountPropertyName%>」 – pencilCake

回答

1

從一個角度來看:如果多次使用此屬性名稱,這是一種很好的做法。這將有助於肯定重構,當你例如改變屬性名稱時,你會發現你也需要改變這個const。

從另一個角度來看,我想這將是醜陋的,當我有10個屬性的類將有10個額外的常量。另一個解決方案,如果你想避免常量或顯式名稱鍵入可以通過反射獲取屬性名稱。

使用這種方法或不,你應該自己決定。

2

恕我直言,將任何'魔術字符串'移動到常量通常是一個好主意。

你可以考慮使用lambda表達式來「挑」的屬性,例如:

GetDataFieldName(studentCollection => studentCollection.Count) 

你將不得不實施GetDataFieldName自己,用一點反思。你可以從MVC看看HtmlHelperExtensions,看看它是如何完成的。這將是最安全的方法,當出現錯誤時會給您提供編譯時錯誤,並允許使用現有的重構工具輕鬆進行屬性重命名。

+0

如果屬性被內聯,它有多安全? –

+0

@ValentinKuzub:內聯不會改變方法的語義,所以它不可能降低對象的安全性或可訪問性。內聯是嚴格的JIT優化,而不是您作爲程序員應該關注的東西。 –

+0

如果屬性是內聯的基於反射的屬性名稱解析將失敗,那我的關注 –

1

我認爲將這種「神奇的字符串」或「神奇的數字」放在某種強類型商店中是很常見的做法。

你可以考慮的東西是以方面定向的方式進行編碼。

例如,對notifypropertychagned的調用可以通過使用aop框架實現的屬性來實現,如PostSharp

[NotifyChange] 
public int Value {get;private set} 

這個工具也有一些缺點,但我認爲在某些場景下,他們可以爲您節省大量的工作

0

我想,如果名字在很多地方使用,那麼它會更容易只是改變他們在這一個地方,並使用你的評論中描述的常量。

但是,對數據庫列名稱和對象屬性名稱的更改意味着對概念數據模型的更改。你多久認爲這會發生?在一個項目的早期階段,雖然概念建模和實現在開發團隊中被並行化,但這可能相當流暢,但是一旦完成了最初的概念建模(無論是以形式化的有意識的方式還是有機的方式),它通常是相當的不太可能像這些基本的東西將會改變。出於這個原因,我認爲這樣做是相對不尋常的,這種技術只會在邊緣情況下產生效果。

+0

然後,常數*不會像以前一樣改變*。更改公共常量會破壞二進制兼容性 – Dyppl

+0

非常正確,但只有在發佈「發佈」程序集時才適用,即供第三方使用,第三方可能會或可能不會在刪除程序集的新版本後重新編譯其代碼。對於內部使用組件,更改常量是可行的。然而,我同意它仍然有點濫用「不變」的概念。 –

0

絕對。是個好主意。順便說一句,我認爲這些東西可以更好地存儲在應用程序設置中,因爲您可以稍後通過覆蓋這些設置在應用程序配置文件中定義這些東西。

這樣做,您將避免重新編譯,如果某些數據庫,POCO或其他任何更改,以及在2010年等較新的Visual Studio版本中,您可以告訴它生成具有「公共」可訪問性的設置,您可以共享任何引用包含它們的程序集的強類型設置。

在一天結束時,我會用DataBindingSettings.StudentCountPropertyName而不是常數更改代碼。

易於管理,更易於重複使用和可讀,就像「使用其設置配置數據綁定」一樣。

檢查這個MSDN文章,詳細瞭解應用程序設置:

1

我不知道我完全理解你的問題,但如果我的理解對不對,我會使用屬性爲例,可以使用Linq中的ColumnAttribute來將屬性映射到數據庫中的特定列(http://msdn.microsoft.com/zh-cn/library/system.data.linq .mapping.columnattribute.dbtype.aspx),如下例所示:

[Column(Storage="ProductID", DbType="VarChar(150)", CanBeNull=False)] 
public string Id { get; set; } 

我永遠不會使用DataFieldName,我會將DataBind用於強類型對象(當然也可以創建一個使用上述屬性的類的接口,所以我很容易就可以在將來更改實現)

相關問題