示例VS解决方案的创建(一)

　　进行项目开发的第一步，是创建出适合自己团队习惯的VS解决方案，虽然我已经提供了项目示例，但毕竟是我创建的，你直接使用可能并不合适，另外你如果尝试模仿重新创建该示例，中间可能碰到各种障碍，特别是项目间的依赖关系。

　　本文的目的是帮助.Net架构初学者能顺利搭建起适合自己的VS解决方案，我会在本文演示曾经用过的几种不同风格的目录结构，你可以根据自己的习惯选择一种并自行修改。

　　本系列假定你已经熟悉如何创建.NET类库等基础知识，并具有.Net开发经验，我不会详细到每一个细节。如果你是.Net初学者，尚未开发过任何实际项目，对你的建议就是关闭本页面，去买本书打好基础，需要提升时再来。

影响VS解决方案结构的因素

分层

　　VS解决方案的创建，与你采用的分层方式密切相关，我在之前的文章已经简单介绍过单层架构和三层架构，本文采用DDD分层架构进行演示，说明项目示例Applications.Managements是怎样创建出来的，并且可以怎样简化。

　　我们平时所说的分层，属于逻辑分层，它按照一定的逻辑层次分离关注点，以便更好的组织代码结构，方便维护。

　　物理分层，是将不同的代码部署到不同的服务器，以提供更高性能和安全性，如果对逻辑分层和物理分层的关系感兴趣，请参考《C#企业应用开发艺术-CSLA.NET框架开发实战》一书。

　　对于逻辑分层，只要将代码分离到不同区域即可，可以按照不同的抽象粒度来组织代码，比如类级别、目录级别、程序集级别。

　　目前普遍采用的是程序集级别进行分层，即不同层的代码放到不同的程序集中。

　　如果期望减少程序集，可以仅创建一个类库，采用目录级别的划分方式，在一个类库中创建不同层的文件夹，各目录放置各层的代码。

　　类级别粒度将不同层的对象合并，通过方法的形式分离各层代码。

　　通过程序集方式分层有诸多好处，比如清晰度、复用性等，我将采用程序集方式进行演示，建议你在项目上也尽量采用这种方式。

功能模块

　　另一个影响VS解决方案创建的因素是功能模块的划分。

　　对于一个业务系统，我们不仅要分层，而且还要划分功能模块，以便对较大的业务问题进行分解，从而降低复杂度，同时在解决某个特定模块的问题时，减少其它模块的干扰。

　　对于领域层，我目前的方式是为每一个功能模块创建一个类库项目，这样做的好处是更方便复用，另外当我需要将这个功能模块分离出去也会更容易。

　　当然，采用文件夹来分隔也同样可行，这是两种不同的风格，我会向你演示如何设计可以更方便的切换。

可复用能力

　　对于一个稍大的项目，把特定业务模块、通用业务模块、通用技术类库放在同一个VS解决方案中，VS解决方案上的项目可能会达到上百个，编译速度将非常缓慢，导致很多不必要的麻烦。

　　我之前已经多次提到，你可以把通用技术类和通用业务类从具体项目中分离出来，这样可以供多个项目使用，每个项目拥有自己的VS解决方案，共享相同的应用框架，这样维护会更容易，编译速度也更快。

　　对于Applications.Managements项目示例，通用技术类库已经抽取到Util解决方案中，Applications.Managements不包含通用性的纯技术代码。

　　我不会为你演示通用业务类的分离，因为代码示例太简单。

其它因素

　　不同的应用程序类型也会影响VS解决方案的创建，比如创建WPF智能客户端应用程序，需要将应用层创建为WCF类库，这样可以将应用服务直接开放出来供WPF调用。对于WPF+WCF的架构，我后续也会进行介绍，如何通过IOC切换本地调用和远程调用，通过这个架构可以在开发时期采用本地方式调用，提高开发效率，部署时切换到WCF远程代理。

　　如果你采用了诸如SOA架构，需要切割子系统部署成服务，可能需要创建更多类型的项目和多个VS解决方案，这些架构也对VS解决方案的创建具有相当影响。由于本人在SOA方面经验尚浅，待后续有更多经验再进行分享。

VS解决方案创建实战

　　下面的步骤演示了我创建VS解决方案的习惯，你不一定要按我的步骤，只要最终达到你的要求即可。

创建表现层MVC项目

　　打开VS解决方案，我使用的是VS 2013，自带了MVC4。

　　创建MVC4项目，项目名称为Applications.Presentation.Managements，解决方案名称为Applications.Managements，MVC项目模板选择“基本”。

　　先来讨论顶级空间的命名，即这里的Applications，要点是尽量抽象。顶级空间名称尽量不使用特定于项目或客户的名称，因为你做下一个项目时，需要大量更改命名空间。我采用Applications，代表抽象的应用程序，任何项目都是应用程序。你也可以采用公司的名称，比如你们公司简称为abc，那么可以这样Abc.Managements。

　　Managements代表这是一个管理系统。Applications.Presentation.Managements说明它是管理系统的表现层，但为什么不用Applications.Managements.Presentation，后面介绍到领域层时我会说明这样做的原因。

　　对于表现层来讲，没有其它层会调用它的API，所以我想保持表现层命名空间的简短，我耍了一个小技巧，将表现层的命名空间改成了Presentation。

　　右键单击Applications.Presentation.Managements项目，选择“属性”，修改“默认命名空间”为Presetation，如下图所示。

　　MVC创建完成后，会在根目录留下一个packages文件夹，MVC项目也会添加packages.config配置，这玩意很有用，Nuget会帮你管理依赖的程序集及版本，当别人运行你的解决方案时缺少程序集，会自动下载还原。但我更喜欢自己手工管理，在Applications.Managements根目录创建Libraries文件夹，我会把packages中必须的几个dll复制进去，其它全部删掉。

　　当然，修改表现层默认命名空间和删除packages属于我的个人习惯，介绍这个是方便你看我的代码，对于你自己的项目，完全没必要这么麻烦。

　　编译通过，继续下面的步骤，后面再返回到表现层。

创建表现层扩展项目

　　在Applications.Managements解决方案上右键，“添加”->“新建项目”，创建一个类库项目，名称为Applications.Presentation.Managements.Extensions。

　　这个项目用来为表现层提供一些支持，比如业务组件的封装。

　　将它的默认命名空间改成Presentation,方便表现层的调用。

　　下面来考虑类库输出的DLL目标位置，默认是在bin\Debug\，表示DLL将输出到类库项目的bin目录下Debug文件夹中。由于我们后续会创建更多的程序集，如果对输出位置不进行统一，将导致每个输出目录都产生大量重复的DLL。

　　右键单击扩展类库，选择属性，找到“生成”选项卡的“输出路径“，修改为..\Release\，如下图所示。

　　下面为Applications.Presentation.Managements项目添加Applications.Presentation.Managements.Extensions扩展项目的引用。

编译通过，继续下面的步骤。

创建应用层项目

　　在Applications.Managements解决方案上创建类库项目，名称为Applications.Services，修改类库输出路径为..\Release\。

　　应用层是为表现层提供服务的，所以表现层Applications.Presentation.Managements需要添加应用层Applications.Services的引用。

　　编译通过，继续下面的步骤。

创建基础设施层项目

　　DDD分层架构中没有了数据访问层的概念，被包含到基础设施层中。

　　基础设施层是为其它各层服务的，按道理说，其它各层应该包含对基础设施层的引用。

　　但是，为了让领域层变得更纯净，一般会应用依赖倒置原则，让基础设施层反过来依赖领域层。

　　一些初学者会产生疑惑，这样不是造成循环引用的死循环了吗？下面谈下我的看法，不一定正确，仅供参考。

　　在《领域驱动设计》一书中，对基础设施层的描述为：基础设施层为各层提供通用的技术能力。

　　可见基础设施层是一个抽象概念，诸如层超类型、公共操作类的封装、数据库的持久化，发邮件，发短信等操作，都是基础设施层的范畴。

　　在我的代码中，大量通用技术，都被封装到Util相关的程序集中，如果需要合并VS解决方案，那么所有的Util项目都是基础设施层的一个组成部分。

　　对于领域层与基础设施层的引用关系，与基础设施层中项目耦合性强弱有关，一般规律是：

领域层只引用基础设施层中低耦合的项目，比如领域层可以引用Util.Core、Util.Domains，这些项目只包含对.NET本身类库的引用，没有外部依赖，也不需要任何配置，领域层依赖这些项目不会降低可复用性和可测试性等指标。
与领域层密切相关的高耦合基础设施层项目，应用依赖倒置原则，先在领域层定义操作接口，由基础设施层项目引用相关领域层项目，并实现该接口。比如仓储代表聚合的集合，仓储的实现依赖于特定数据访问技术，甚至包含SQL语句，所以具有很高的耦合，且与领域层特定模块密切相关。如果领域层直接引用数据访问实现的程序集，将严重降低领域层的可复用性，且更难测试。
与领域层关系不大的高耦合基础设施层项目，应用分离接口模式，将操作接口与具体实现分离到基础设施层的不同项目中。比如工作单元的接口IApplicationUnitOfWork，它与领域层基本没啥关系，如果你的领域层只包含一个类库项目，把IApplicationUnitOfWork放到领域层项目中也没什么问题，我之前一直是这样干的，但如果你的领域层包含多个项目，你应该放到哪一个项目中？单独创建一个基础设施层项目来放置这些接口会好一些。

（未完待续…）