作为一名Java程序员,我习惯于使用包结构(com.domain.appname.tier)。现在我开始研究C#项目,其中所有的项目都只有一层深度:
例如:
ProjectA
- Utilities.cs
- Validation.cs
- ...
- Extraction.cs
所有.cs文件长度大约为2500行......
您如何对C#中的类和命名空间进行排序,以使其有意义,并且保持源文件大小合理?
作为一名Java程序员,我习惯于使用包结构(com.domain.appname.tier)。现在我开始研究C#项目,其中所有的项目都只有一层深度:
例如:
ProjectA
所有.cs文件长度大约为2500行......
您如何对C#中的类和命名空间进行排序,以使其有意义,并且保持源文件大小合理?
我认为在Java中你的做法是一样的:
你加入的项目似乎不是很有结构性,也不是良好源代码组织的好例子。
partial class
的有效性问题,这显然会导致每个类有多个文件。(或者也可能是相反的,partial class
的设计引发了对你的第二个观点的有效性的质疑 :)) - Noctis在Java中,同样地,你只需要付出一些努力 :) 一些C#开发者,特别是有VB背景的人,倾向于编写非常长的类并将它们放在顶层。
我首先会将类分组到功能区域中,例如与授权相关的区域将放在项目内的一个文件夹下。
然后更新文件夹中类的命名空间以反映更改,Resharper可以为您完成此操作,较新版本的VS可能也会这样做。
最后(如果您能够),我会开始将类分解为更小、更易管理的大小。
该项目有一个默认命名空间,本例中为CompanyName.ProjectName。 源文件按逻辑组织成目录结构。在此示例中,我的WF4活动设计器以Activities的形式组织在名为Designers的文件夹中。
VS的工作方式是,当您在项目中创建目录时,也会创建命名空间。因此,如果我要在所示目录中添加名为“Foo”的新活动设计器,则其命名空间将为
"CompanyName.ProjectName.Activities.Designers"
Visual Studio会使用默认命名空间,然后根据文件夹结构确定特定文件的命名空间。当然,一旦文件被创建,并且您移动了一个文件,它不会自动重构。但是这个系统不仅非常适合控制类的命名空间,也适合保持文件的组织。
和在Java中一样。
在Java中,包将类组织到物理目录中。我不确定这一点,但编译器甚至鼓励这种约定(如果我没记错的话)。在C#中,您不必将类组织到与命名空间匹配的单独目录中,但这是一种非常常见的约定。
说到C#中的命名空间,它们不遵循“com.domain.appname.tier”约定,而是使用“Company.Product.Tier”格式。
如何重新组织大型类取决于应用程序。这是应用面向对象编程准则的练习,并适用于Java和C#。
如果你深入参与了这个项目,我建议你花些时间重新设计结构,就像在Java中一样,考虑到包在C#中等同于命名空间。