I'd go with something other than 'Page'. The 'Page' class that is built into .NET is a very generic class that is commonly known as part of ASP.NET. You could easily confuse other developers (or even yourself, a few months down the road if you don't look at it for a while).
I usually go with a naming convention such as:
ApplicationName + "Page"
I also like to follow the MS .NET naming guidelines of only capitalizing the first letter of an acronym longer than 2 characters. Since 'MVCMS' can be confused for the 'MVC' architecture style if read incorrectly, I wouldn't use 'MvcmsPage' or 'MVCmsPage', I'd call it something like this:
MvCmsPage
This is descriptive and fairly easy to read and understand.
Of course it's really up to you. Mainly it's a matter of preference. Just don't use 'Page' as it will make some developers angry (such as myself).
I think the term you were looking for is namespace.
I don't think I would rely on namespace differentiation for such a fundamental class in the System.Web space. If you were writing a console-based notification mechanism then it might be ok, but since you're working in the web arena, I'd avoid it. My vote would be to use the namespace as the main differentiator and name it something simple, like ContentPage so you would have something like MvcCms.Web.ContentPage as the full name of the class.
If you do it this way you can import both your namespace and System.Web and still be able to differentiate the classes AND you have a short name that makes sense and isn't cumbersome to use or reference (when speaking about it).
To me, since you're developing a CMS, the object at the root is the Content. So either MvCmsContent, CmsContent, or just Content would seem fine to me. Isn't naming always the hardest part of a project?
We had a similar issue and just went with CMSPage. It's a bit less cumbersome than the MVCMSPage, but still obviously CMS and you can further extend that class for multiple systems in the future if need be.
I'm thinking the "page" you're referring as the application's equivalent of a database record. As others are saying this it's a rather loaded term. Here's a few random ideas:
Node
View
PageRecord
CmsPage
WebDocument
ContentPage
Your choice should try to convey the essence of the object type. I'd avoid putting the product name into the class name. I prefer namespaces for that.
发布评论
评论（5）
我会选择“
Page”以外的其他内容。 .NET 中内置的“Page”类是一个非常通用的类，通常称为 ASP.NET 的一部分。 您可能很容易让其他开发人员感到困惑（甚至是您自己，如果您暂时不看的话，几个月后）。我通常采用这样的命名约定：
我还喜欢遵循 MS .NET 命名准则，即仅将长度超过 2 个字符的首字母缩略词的第一个字母大写。 由于如果读取不正确，“
MVCMS”可能会与“MVC”架构风格混淆，因此我不会使用“MvcmsPage”或“MVCmsPage” ’，我会这样称呼它：这是描述性的，相当容易阅读和理解。
当然，这完全取决于你。 主要是偏好问题。 只是不要使用“
Page”，因为它会让一些开发人员（例如我自己）生气。I'd go with something other than '
Page'. The 'Page' class that is built into .NET is a very generic class that is commonly known as part of ASP.NET. You could easily confuse other developers (or even yourself, a few months down the road if you don't look at it for a while).I usually go with a naming convention such as:
I also like to follow the MS .NET naming guidelines of only capitalizing the first letter of an acronym longer than 2 characters. Since '
MVCMS' can be confused for the 'MVC' architecture style if read incorrectly, I wouldn't use 'MvcmsPage' or 'MVCmsPage', I'd call it something like this:This is descriptive and fairly easy to read and understand.
Of course it's really up to you. Mainly it's a matter of preference. Just don't use '
Page' as it will make some developers angry (such as myself).我认为您正在寻找的术语是
命名空间。我不认为我会依赖 System.Web 空间中这样一个基本类的命名空间差异。 如果您正在编写基于控制台的通知机制，那么它可能没问题，但由于您在网络领域工作，所以我会避免它。 我的投票是使用命名空间作为主要区别因素，并将其命名为简单的名称，例如
ContentPage，这样您就会有像MvcCms.Web.ContentPage这样的全名班上。如果你这样做，你可以导入你的命名空间和 System.Web ，并且仍然能够区分这些类，并且你有一个有意义的短名称，并且使用或引用并不麻烦（当谈论它时）。
I think the term you were looking for is
namespace.I don't think I would rely on namespace differentiation for such a fundamental class in the System.Web space. If you were writing a console-based notification mechanism then it might be ok, but since you're working in the web arena, I'd avoid it. My vote would be to use the namespace as the main differentiator and name it something simple, like
ContentPageso you would have something likeMvcCms.Web.ContentPageas the full name of the class.If you do it this way you can import both your namespace and
System.Weband still be able to differentiate the classes AND you have a short name that makes sense and isn't cumbersome to use or reference (when speaking about it).对我来说，由于您正在开发 CMS，因此根对象就是内容。 因此，MvCmsContent、CmsContent 或仅 Content 对我来说似乎都不错。 命名难道不是项目中最难的部分吗？
To me, since you're developing a CMS, the object at the root is the Content. So either MvCmsContent, CmsContent, or just Content would seem fine to me. Isn't naming always the hardest part of a project?
我们遇到了类似的问题，所以就选择了 CMSPage。 它比 MVCMSPage 稍微简单一些，但显然仍然是 CMS，如果需要的话，您可以在将来为多个系统进一步扩展该类。
We had a similar issue and just went with CMSPage. It's a bit less cumbersome than the MVCMSPage, but still obviously CMS and you can further extend that class for multiple systems in the future if need be.
我认为您所指的“页面”相当于应用程序的数据库记录。 正如其他人所说，这是一个相当负载的术语。 这里有一些随机的想法：
您的选择应该尝试传达对象类型的本质。 我会避免将产品名称放入类名称中。 我更喜欢命名空间。
I'm thinking the "page" you're referring as the application's equivalent of a database record. As others are saying this it's a rather loaded term. Here's a few random ideas:
Your choice should try to convey the essence of the object type. I'd avoid putting the product name into the class name. I prefer namespaces for that.