关于项目架构设计的一些规范

几个规范：

1. 单元测试设计
2. DTO 命名
3. Web API 命名
4. 待补充...

1. 单元测试设计

可以参考微软开源项目的单元测试，地址：https://github.com/aspnet

首先是单元测试项目创建，我们一般会对各个类库项目进行单元测试，比如 Application、Repository 等等，我们是创建一个单元测试项目呢？还是多个呢？看下 EntityFramework 中的 Test 项目：

一般情况下，单元测试项目一一对应于要测试的项目，比如 EntityFramework.Core 对应于 EntityFramework.Core.Tests，还有一种创建方式是，整个解决方案只有一个单元测试项目，比如 EntityFramework.Tests，然后针对各个项目的测试用文件夹进行归类，哪种创建方式更好呢？简单总结下：

• 一一对应方式：隔离性更好，单个类库测试运行更加轻快，坏处就是，解决方案项目越多的话，测试项目也就越多。
• 大一统方式：一个测试项目对应多个类库项目，减少不必要的测试项目创建，坏处就是，解决方案项目越多的话，测试代码文件或目录会更加混乱，并且 packages 包会巨大。

我个人觉得，还是一一对应的方式比较好，毕竟一个测试项目的大小空间，并不是什么问题。

除去单元测试项目的创建，还有就是一些命名规范，大致总结下：

• 测试项目命名：一般是在要测试类库项目的后面，加上 Tests，比如 EntityFramework.Core.Tests。
• 测试代码文件命名：一般是在要测试类的后面，加上 Test，比如 DbContextTest。
• 测试方法命名：下面详细说下这个。

关于测试方法的命名，在微软开源项目里是“五花八门”，我随便整几个：

• Microsoft.Data.Entity.Tests.DbContextTest.Each_context_gets_new_scoped_services()
• Microsoft.AspNet.Mvc.Core.Test.ActionExecutorTest.AsyncAction_TaskReturnType()
• Microsoft.Dnx.Runtime.Tests.ApplicationEnvironmentFactsTest.GetDataReturnsNullForNonExistantKey()
• Microsoft.AspNet.Http.Tests.FormFeatureTest.ReadFormAsync_SimpleData_ReturnsParsedFormCollection()
• ...

哪种命名方式会比较好呢？其实没有准确的答案，但可以肯定的是，一种测试方法命名方式，在一个解决方案中必须是统一的，测试方法命名最重要的目的是，更好的表达这个测试方法要干什么，并且测试方法名称是给开发人员看的，如果你看一个测试方法名称，就知道它干的什么事，那么这种测试命名方式就是好的，如果团队协作开发一个项目的话，团队之间最好要统一起来，我个人比较倾向于上面第四种。

2. DTO 命名

DTO（Data Transfer Objects）－数据传输对象，有关 DTO 的项目及类，该如何命名呢？可以参考这篇博文：Create Data Transfer Objects (DTOs)

简单总结下：

• DTO 项目命名：Sample.App.DTOs
• DTO 类命名：BlogDTO

问题就是 DTO 单词是否大小写，还有就是最后的 s，以此类推，那什么情况下要加 s 呢？比如 Services、Interfaces、Controllers、Models 等等，这类项目的共同点就是，项目下面是相似类的集合，和这种情况不同的是，比如这个项目 Sample.App.Infrastructure，就没有 s。

3. Web API 命名

Web API 全称 ASP.NET Web API，Web 的项目可以命名为 Sample.App.Web，Web API 的项目改如何命名呢？三种方式：

• Sample.App.WebApi
• Sample.App.WebAPI
• Sample.App.Web.API

哪种方式比较好呢？暂时没有 Google 到示例，不过，我个人倾向于第二种。