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

几个规范：

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 到示例，不过，我我的倾向于第二种。