有关C＃CMS命名约定的快速问题

Question

我正在构建一个CMS，并且在我和其他开发人员之间争论了类的命名约定。问题出现在“Page”中，因为它是典型库中的公共类。

一个自然的响应是将它称为MVCMSPage（其中MVCMS是cms的名称）或依赖于通过dll引用类（不能想到术语atm ..）但两者似乎对他们有一些代码的暗示。

你会建议什么？

由于

Answer 1

我会选择“Page”之外的其他内容。 .NET中内置的“Page”类是一个非常通用的类，通常称为ASP.NET的一部分。你可能很容易混淆其他开发者（或者甚至是你自己，几个月后如果你不看一段时间）。

我通常使用命名约定，例如：

ApplicationName + "Page"

我还想遵循MS .NET命名准则，只使用长度超过2个字符的首字母缩写词的第一个字母。如果错误地读取“MVCMS”可能会混淆“MVC”架构风格，我不会使用“MvcmsPage”或“MVCmsPage”，我会称之为这样：

MvCmsPage

这是描述性的，相当容易阅读和理解。

当然，这取决于你。主要是偏好问题。只是不要使用“Page”因为它会让一些开发人员感到愤怒（比如我自己）。

Answer 2

我认为您所寻找的术语是namespace。

我认为我不会依赖于System.Web空间中这样一个基础类的命名空间区分。如果您正在编写基于控制台的通知机制，那么它可能没问题，但由于您在Web领域工作，我会避免它。我的投票方式是使用命名空间作为主要区别，并将其命名为简单的名称，例如ContentPage，这样您就可以使用类似MvcCms.Web.ContentPage的内容作为类的全名。

如果你这样做，你可以导入你的命名空间和System.Web，并且仍然可以区分类和你有一个有意义的简短名称，并且使用或引用并不麻烦（说话时）关于它）。

Answer 3

对我而言，由于您正在开发CMS，因此根目录中的对象是内容。所以MvCmsContent，CmsContent或者只是内容对我来说似乎都很好。不是命名总是项目中最难的部分吗？

Answer 4

我们遇到了类似的问题，只是选择了CMSPage。它比MVCMSPage稍微麻烦一点，但显然仍然是CMS，如果需要，您可以在将来进一步扩展该类用于多个系统。

Answer 5

我认为你所指的“页面”是应用程序相当于数据库记录的。正如其他人所说，这是一个相当负荷的术语。以下是一些随意的想法：

• 节点
• 查看
• PageRecord
• CmsPage
• WebDocument
• ContentPage

您的选择应该尝试传达对象类型的本质。我会避免将产品名称放入类名中。我更喜欢名称空间。