我正在构建一个 CMS，而我和其他相关开发人员就类的命名约定进行了辩论。这个问题特别出现在“Page”中，因为它是典型库中可用的公共类。
一个自然的反应是称它为 MVCMSPage（其中 MVCMS 是 cms 的未来名称）或依赖于通过 dll 引用类（无法想到术语 atm..），但两者似乎给他们一点代码味道。
你有什么建议？
谢谢
【问题讨论】：
标签： c# content-management-system naming-conventions
我会选择“Page”以外的东西。 .NET 中内置的“Page”类是一个非常通用的类，通常被称为 ASP.NET 的一部分。您很容易混淆其他开发人员（甚至您自己，如果您暂时不看的话，几个月后）。
我通常使用如下命名约定：
ApplicationName + "Page"
我还喜欢遵循 MS .NET 命名准则，即仅将超过 2 个字符的首字母缩写词的首字母大写。因为如果读取错误，'MVCMS'可能会与'MVC'架构风格混淆，我不会使用'MvcmsPage'或'MVCmsPage'，我会这样称呼它：
MvCmsPage
这是描述性的，相当容易阅读和理解。
当然，这完全取决于您。主要是偏好问题。只是不要使用“Page”，因为它会激怒一些开发者（比如我自己）。
【讨论】：
我认为您要查找的术语是namespace。
对于 System.Web 空间中的这样一个基本类，我认为我不会依赖命名空间区分。如果您正在编写基于控制台的通知机制，那么它可能没问题，但由于您在网络领域工作，我会避免它。我的投票是使用命名空间作为主要区别并将其命名为简单的名称，例如ContentPage，这样您就可以将MvcCms.Web.ContentPage 之类的名称作为类的全名。
如果你这样做，你可以同时导入你的命名空间和 System.Web 并且仍然能够区分这些类并且你有一个有意义的短名称并且使用或引用不麻烦（谈到它时)。
【讨论】：
对我来说，由于您正在开发 CMS，因此根目录下的对象就是内容。所以无论是 MvCmsContent、CmsContent 还是只是 Content 对我来说都很好。命名不是项目中最难的部分吗？
【讨论】：
我们遇到了类似的问题，只是选择了 CMSPage。它比 MVCMSPage 稍微简单一些，但显然仍然是 CMS，如果需要，您可以在未来进一步扩展该类以用于多个系统。
【讨论】：
我认为您所指的“页面”相当于应用程序的数据库记录。正如其他人所说，这是一个相当负荷的术语。以下是一些随机的想法：
你的选择应该尽量传达对象类型的本质。我会避免将产品名称放入类名中。我更喜欢命名空间。
【讨论】：