相关疑难解决方法(0)

我经常读到这个框架太大了,一个开发人员无法体验它的每一部分.有一些实际数字肯定有助于把事情放在眼里.

MSDN似乎列出了所有这些,但没有实际的数字(从我能看到的),花费数小时计算它们并不是我对生产时间的看法.

• 命名空间数
• 课程数量
• 结构数量
• 接口数量

我意识到还有代表,枚举,事件等,但上述类型是最感兴趣的.

此外,基类库(BCL)中的类型数量以及整个框架类库(FCL)的大小将是有趣的.

这些信息有两种用途:

首先,要了解您实际使用的整体框架的数量以及您还需要学习多少.

其次,来自其他平台(和非技术人员)的许多程序员经常会惊讶于程序员可以将大部分时间花在".NET Framework"中.有一些数字肯定有助于解释为什么这不是狭隘的技能/经验的迹象.

[更新]

使用安德鲁的代码(在我的.NET 3.5 SP1系统上),我得到:

Classes: 12688
Value types: 4438
Interfaces: 1296

抽象

哪个名字更好？

• Domain.PersonService
• DomainServices.PersonService
• DomainServices.PersonDomainService(考虑一些较长的名字PersonDomainServiceModelDecorator)

或者是其他东西？

情况

我们有一个框架,每个层都有一些基类.防爆.存储库,域服务,UI等

每个逻辑层都有一个名称,用作其名称空间:

• 包含存储库的数据层的"数据"; 防爆.Fx.Data.DbContextRepository
• 域(非Web)服务层的"服务"; 防爆.Fx.Services.CrudService
• Web UI层的"Web.UI"; 防爆.Fx.Web.UI.Controllers.CrudController

对于一些额外的层,我们也遵循相同的终端项目规则:

• "数据"Ex. Project.Data.PersonRepository
• "服务"Ex. Project.Services.PersonService
• "Web.UI"Ex. Project.Web.UI.Controllers.PersonController
• 代码优先实体的"实体"; 防爆.Entities.Person
• 对象模型的"模型"; 防爆.Models.Person.Criteria,Models.Person.PersonDeleteModel

我的重点是"域名服务"层,但欢迎任何关于其他层的想法.

我们最终得出的结论是"服务"不是"域服务"的合适名称,因为它可能导致"Web服务"或"域服务"层之间的歧义.

现在我们将"服务"命名空间更改为"域"或"域服务".但我们还有另一个问题.我们为每个域服务类(例如PersonService)添加了"服务"后缀.现在,使用"DomainService"后缀(例如DomainServices.PersonDomainServer或者DomainServices.DomainPersonService)似乎很难看.

因此,使用"Domain"作为命名空间可能更漂亮,而类名称显示它们是域命名空间(Ex.Domain.PersonService)下的服务.

每个版本(1.0,1.1,2.0,3.0,3.5),.NET框架中有多少个类？

我正在寻找我将要在硕士课程中为课程提供的演示文稿的信息.