有关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

你的选择应尽量传达对象的本质类型。我会避免把产品名称放入类名中。我更喜欢命名空间。