任意命名約定提問關於Business Objects公司

Question

好吧，你做Business.Name或Business.BusinessName SubCategory.ID或數據庫SubCategory.SubCategoryID

怎麼樣？

爲什麼？

我與兩個人都被撕裂。很想有是一個「正確答案」

Answer 1

使用ID的主要缺點，姓名等是，你必須用表名限定他們，如果你正在編寫一個SQL連接重疊兩個表。

儘管如此，我覺得它更簡潔，可讀性只使用ID和姓名 - 你的代碼，並表將「流」更容易過去的目光。更容易打字和減少冗餘。在SQL查詢中輸入SELECT Business.Name FROM ...實際上並不比輸入SELECT BusinessName FROM更麻煩...

通常，如果我發現自己重複語義信息，它會提醒我尋找消除方法它或至少認識到它重複的原因。這可能是小規模（屬性名稱）或大規模（行爲模式或公共類結構）。

Answer 2

唯一的「正確」的答案是一致的。預先決定你將在一個項目中使用哪一個，並堅持下去。

Answer 3

對於像「名稱」和「ID」很常見的性質，我已經使用的慣例是不把實體名稱領域。對於更不尋常的屬性，我確實把實體名稱。

這是一個命名約定的決定，但我沒有後悔項目這是約定，如果你把每個ID的實體名稱，它看起來是太冗長了。

Answer 4

我們對任何主鍵都做ID。話說SubCategory.SubCategoryID似乎是多餘的，

Answer 5

我可能不是正確的，但我認爲Id是美味的菜。

thing.id
，因爲如果你要編寫與你交易的對象和需求的主鍵的任何反射的東西，它的方式更容易知道它無處不在，然後試圖用一個公式來確定它。

至於其他的，那總的偏好，我沒有看到比浪費輸入其他字符時其他任何真正的影響，其.NET，所以沒有人真正類型的命名空間呢。