我們將在傳統數據庫（使用.NET C＃）上開發一個新系統，大約有500個表。我們選擇爲我們的數據訪問層使用ORM工具。問題在於實體的namig約定。實體名稱與表名
數據庫中的表格有名稱，如TB_CUST - 包含客戶數據的表格或TP_COMP_CARS-公司汽車。前綴的第一個字母定義模塊，第二個字母定義與其他表格的關係。
我想命名實體更有意義。像TB_CUST只是客戶或客戶實體。當然會有一個註釋指向它的表名。
但是DBA和程序員在一個人，不要這樣的名字。他希望實體名稱與表名完全相同。他說他必須記住兩個名字，這將是困難和混亂。我不得不說他不太熟悉面向對象的原理。
但是如果像TP_COMP_CARS這樣的實體名稱應該有方法名稱，如Get TP_COMP_CARS或SaveTP_COMP_CARS ..我認爲這是不可讀和醜陋的。
所以請告訴我你的意見。誰是對的，爲什麼。
預先感謝您
的ORM工具的整體思路，是避免記憶數據庫對象的需要。 我們通常創建一個包含所有表和列名的數據庫類，所以沒有人需要記住任何東西，ORM應該將數據庫「名稱」映射到普通實體。
雖然它是主觀的，在我看來，你是對的，他是錯的....
誰來用新的代碼大多是工作？那個人應該決定命名慣例恕我直言。
的個人當然，我會去你的解決方案，因爲前面已經提到的，如果你使用ORM你不需要打DB直接頻繁。
我不同意第一部分。如果將要使用代碼的人改變，該怎麼辦？ – 2009-12-04 10:21:08
看看我是第一個選擇改變名稱以符合範例的人。我只是想找出硬幣的這一面。但我並不堅持這一點。我希望我不會對我的觀點得到更多的否定:-) – Petros 2009-12-04 10:38:03
+1爲什麼選擇倒票？人剛剛表達了他的看法，這正是你的問題。錯誤信息可能是反對票，但分歧不應該是反對票。 – 2009-12-22 10:19:23
正如你可以使用的名稱，如TB_CUST其中的行爲直接與數據庫但後來使用的名稱，如客戶對您的數據傳輸對象的妥協。編寫好的代碼涉及到創建可能正在使用的任何數據源的抽象。整個代碼都有GetTB_CUST()有點像在這個地方點綴着GetTB_CUSTFromThatSQLDatabaseWeHave()。
在兩個不同域中使用的命名約定根本不對齊。 Java中，例如，哈薩很好定義的規則/慣例類名和場名，其中資本是顯著。通常，您的應用程序可能會移植到具有不同命名標準的完全不同的數據庫，因此要求業務邏輯中的名稱與數據庫中的名稱保持一致是不合理的。考慮一個稍微更復雜的映射，一個實體可能不對應一個表。
而且，真的，拜託...
Customer == TB_CUST
這只是不是那麼難！我和你在一起，使得這些名字在ORM中的代碼和映射中有意義。對於DBA /程序員的學習不應該那麼痛苦，我的猜測是這些事情在預期中比現實感覺更糟。
以及GC_SU和S_OE或TB_FAKOE如何？我不知道那裏有什麼:-) – user137348 2009-12-04 09:34:34
這就是爲什麼你應該從數據庫中刪除原來的名字。如果它需要查找一些過時的文檔來了解字段的含義，那麼編碼時可能會犯錯誤。因此，您可以將ORM映射看作字段含義的實際文檔。好多了。 – 2009-12-04 11:34:45
我個人很討厭這樣的表名，但它是一個遺留系統，我確信DBA不喜歡重命名錶。重命名錶可能是一個選項。您只需創建代表舊錶格名稱的視圖，以便在開發新系統時您的遺留系統繼續運行。如果這不是一個選項，您可以使用ORM將表名映射到實體名稱。或者，您可以將數據訪問層中的ORM抽象出來，並在域模型中定義好的實體名稱，讓您的DAL進行名稱轉換。
「我不得不說，他沒有真正熟悉OOP的原則。
但在像TP_COMP_CARS實體名稱的情況下，應該有方法的名字，如獲取TP_COMP_CARS或SaveTP_COMP_CARS..I認爲這是不可讀醜，
所以請告訴我你的意見，誰是對的，爲什麼。
哪些名稱給予您的IT系統管理的東西完全與「OOP原則」無關。
對於「標準」「getter和setter」方法的名稱也是如此：這些只是協議和約定，而不是「OOP原則」。
問題是代碼的某種「人體工程學」（因此也是自我記錄的價值）。
確實，getTP_COMP_CARS看起來很醜陋（儘管不是，正如你聲稱的那樣，「不可讀」）。同樣，如果你開始遵守「更現代」的命名規則，那麼就必須有某個地方需要維護同義名稱之間的映射。 （和TP_COMP_CARS這樣的名稱比完整的「自然語言詞」名稱更少自我記錄是錯誤的：通常這樣的名字是由一組非常小的助記詞構成的，它們一遍又一遍地用於相同的意義，讓任何人都能夠記住它們，這足夠簡單。）
對此沒有正確和錯誤。像我們現在居住的那些日子那樣的名字是通常的慣例。至少，這些名稱通常具有不區分大小寫的好處，與由所謂的「更現代」系統強加給我們的braindead（因爲區分大小寫）命名規則相反。
從現在起二十年後，人們會稱這些天我們使用的命名約定「braindead」。
如果數據庫中有500個表 - 你已經有了一個挑戰，保持這些名字直。希望你有元數據和一些更有意義的圖形模型。
當您創建接下來的500個ORM對象時，您將面臨另一個挑戰。即使你給他們有意義的名字，它仍然太多，真的希望一切都會變得明顯。所以，現在你有兩個問題。
如果沒有辦法將這兩組500個表連接在一起 - 那麼你有3個問題。考慮調試ORM中查詢的性能，並以他無法識別的名稱前往DBA。考慮一下你精心設計的名字 - 當你創建直接打到數據庫的報表時，必須忽略它。
所以，我會盡量使用ORM中的數據庫名稱。但我會調整一些東西：
+1這就是ORM的要點：擺脫braindead表命名約定:) – 2009-12-04 09:25:41
這是現有的DBA/Programmer傢伙的一些痛苦，他有他的美好的世界，對他而言這是改變。但在這種情況下，我重視在業務邏輯中仔細選擇域名以節省一些工作。 – djna 2009-12-04 09:51:57
+1 - 我還可以補充一點：ORM工具意味着您可以開發應用程序層，而無需對精確的表名和列名進行硬編碼。存儲過程和硬編碼SQL使得難以重構數據。在應用程序層中良好地使用ORM和類型安全的實體對象使重構數據變得容易得多。 – 2014-07-29 08:19:31