如何命名和组织 CLASS 文件？
我在 C# 中使用 ASP.NET，我在开发方面还很陌生，所以我希望得到专家的一些建议:-)。
问题：
- 组织类文件的最佳实践是什么？
- 你用什么样的名字？
- 对于Web应用程序项目，如何命名NAMESPACE？
就我而言，我正在构建一个简单的 CMS。我认为文件结构是这样的：
- AppCode
- Common
- UserDataInput.cs
- ExternalLibrary
- BusinessLayer
- FrontEnd
- BackEnd
- AccessLayer
谢谢大家与我分享你们的想法！再见
I use ASP.NET in C#, I am pretty new at developing so I would like have some advice from experts :-).
Questions:
- What is the best practice to organizing CLASS FILES?
- What kind of name do you use?
- For Web Application Project, how do you name NAMESPACE?
In my Case I am building a simple CMS. I thought the FILE structure like this:
- AppCode
- Common
- UserDataInput.cs
- ExternalLibrary
- BusinessLayer
- FrontEnd
- BackEnd
- AccessLayer
Thanks guys for sharing your thoughts with me! Bye
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
每个人的命名约定都不同，没有正确的答案，只有最佳实践，但也有很多错误的答案。当谈到面向对象编程时，不要为了模块化而过度杀伤，有些东西，比如将在后端使用的 DataHelpers 项目，可能是你随身携带的东西，但是，比如说一个 gravatar 帮助程序类（这是一个实际的类） Microsoft.Web.Helpers 下）是一种过度杀伤力，因为您只需要
String.Format()和 md5 哈希方法即可。当涉及到模块化时，它几乎可以让您在另一个项目中再次需要什么。这是不言而喻的，但是，请确保您命名的方法类在您工作的上下文中有意义，当使用 asp.net MVC 时，我将有一个 CMS.Controller 项目和一个 CMS.View 项目，但所有内容都将在下面CMS 解决方案，在经典 ASP.net 中我将其命名为 CMS.BL 或 CMS.Web。我不会在 AppCode 下放置任何内容，只是将项目添加到您的解决方案中，并且不要将它们称为 Common，当跨解决方案携带代码时，它们会因 *.Common 命名空间而变得拥挤。
因此，根据项目的用途对代码进行分类，并确保实现一个层次结构，以便当您在项目中实现这种模式时，继承自 Xbase 的 classX 在项目项目中处于相同的层次结构下与 Xbase 位于 CSM.Web.Core 下和 classX 位于 CMS.Web 下相比，您会更加成功，这将为循环引用铺平道路。
这是我正在处理的一个项目的示例，它最初是一个 MVC 应用程序，但后来变成了一个包含 winforms 和一切的项目。
只要事情对你有意义并且你感到舒服，你就可以摆脱一切，就像下面的解决方案中我有一个继承自 Entities.Netsis 的 Data.Netsis.Entities 。
希望这有帮助。
Naming conventions are different for everyone there are no right answers only best practices but there are plenty of wrong ones. When it comes to object oriented programming don't overkill for the sake of modularity some things, like a DataHelpers project which would be be used in your backend could be something you carry around but, say a gravatar helper class (which is an actual class under Microsoft.Web.Helpers) is an overkill simply because
String.Format()and a md5 hashing method is all you need for that. It's pretty much eyeballing what you would need again in another project when it comes to modularity.This goes without saying but, make sure what you name your methods classes make sense in the context that you work, when working with asp.net MVC what I would have a CMS.Controller project and a CMS.View project but all will be under the CMS solution where in classic ASP.net I would have named CMS.BL or CMS.Web. I wouldn't place anything under AppCode just add projects to your solutions and don't call them Common, when carrying your code across solutions they become overcrowded with *.Common namespaces.
So classify your code trough projects in terms of what they are used for and be sure to implement a hierarchy so that your classX that inherits from Xbase is under same sort of hierarchy in temrs of project when you implement this kind of a pattern in your projects you will be more sucsessfull as opposed to Xbase being under CSM.Web.Core and classX under CMS.Web which will later on pave the road to circular references.
Here is an example of a project im working on, it started as a MVC application but later turned into a prject that has winforms and everything.
As long as stuff make sense to you and you are comfortable with, you can get away with everything, like there in the solution below i have a Data.Netsis.Entities that inherits from Entities.Netsis.
Hope this helps.