有關C＃CMS的命名約定的快速問題

Question

我正在構建一個CMS，並且其他開發人員和我自己之間一直在討論類的命名約定。問題出現在「頁面」中，因爲它是典型圖書館中的公共課程。

一個自然的反應是將其稱爲MVCMSPage（其中MVCMS是cms的未來名稱）或依靠通過dll引用類（不能認爲術語atm ..）似乎對他們有一點代碼味道。

你會建議什麼？

感謝

Answer 1

我會去比 'Page' 以外的東西。內置於.NET中的'Page'類是一個非常通用的類，通常稱爲ASP.NET的一部分。你可能很容易混淆其他開發人員（或者甚至是你自己，如果你暫時不看它，幾個月後）。

我通常的命名約定去如：

ApplicationName + "Page" 

我也喜歡跟着MS .NET命名的唯一資本的縮寫超過2個字符的第一個字母的指導方針。由於「MVCMS」可如果讀錯，我不會用「MvcmsPage」或「MVCmsPage」混淆爲「MVC」的建築風格，我把它叫做是這樣的：

MvCmsPage 

這是描述性的並且相當容易閱讀和理解。

當然這真的取決於你。主要是一個偏好問題。只是不要使用'Page'，因爲它會讓一些開發者生氣（比如我自己）。

Answer 2

我認爲你要找的術語是namespace。

我不認爲我會依賴於System.Web空間中這樣一個基礎類的命名空間差異化。如果你正在編寫一個基於控制檯的通知機制，那麼它可能是好的，但由於你在網絡舞臺上工作，我會避免它。我的投票將是使用名稱空間作爲主要的區別，並將其命名爲簡單的名稱，如ContentPage，因此您可以將類似MvcCms.Web.ContentPage這樣的名稱作爲該類的全名。

如果你這樣做，你可以導入你的名字空間和System.Web，但仍然能夠區分類，並且你有一個簡短的名字是有意義的，並且不會使用或引用繁瑣（當談到它時） 。

Answer 3

對我而言，由於您正在開發CMS，因此根目錄中的對象就是內容。因此，無論是MvCmsContent，CmsContent還是Content都對我來說看起來很好。是不是總是命名項目中最難的部分？

Answer 4

我們遇到過類似的問題，只能用CMSPage。這比MVCMSPage稍微麻煩一點，但顯然仍然是CMS，如果需要的話，您可以在將來爲多個系統進一步擴展該類。

Answer 5

我在想你所指的「頁面」是應用程序的數據庫記錄的等價物。正如其他人所說的那樣，這是一個相當重要的術語。下面是一些隨機的想法：

• 節點
• 查看
• PageRecord
• CmsPage
• WebDocument
• ContentPage

你的選擇應儘量傳達對象的本質類型。我會避免把產品名稱放入類名中。我更喜歡命名空間。