标签：
进行项目开发的第一步，是创建出适合自己团队习惯的VS解决方案，虽然我已经提供了项目示例，但毕竟是我创建的，你直接使用可能并不合适，另外你如果尝试模仿重新创建该示例，中间可能碰到各种障碍，特别是项目间的依赖关系。
本文的目的是帮助.Net架构初学者能顺利搭建起适合自己的VS解决方案，我会在本文演示曾经用过的几种不同风格的目录结构，你可以根据自己的习惯选择一种并自行修改。
本系列假定你已经熟悉如何创建.NET类库等基础知识，并具有.Net开发经验，我不会详细到每一个细节。如果你是.Net初学者，尚未开发过任何实际项目，对你的建议就是关闭本页面，去买本书打好基础，需要提升时再来。
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解决方案，我使用的是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项目都是基础设施层的一个组成部分。
对于领域层与基础设施层的引用关系，与基础设施层中项目耦合性强弱有关，一般规律是：
（未完待续…）
a) MYSQL的乐观离线锁与SQL SERVER显著不同，主要参考王刚的这篇：EF6 Code First 系列 （三）：在MySql中使用和SqlServer一致的RowVersion并发控制。不过对于Sql Server，我还是使用IsRowVersion，毕竟这是大部分项目的主打。
b) 通过一个简单的Ioc配置，即可将Sql Server切换到MySql。
c) MySql不支持Sql Server的schema，我使用.分隔MySql表名模拟schema，以保持与Sql Server的一致性风格，这需要一点EF映射技巧。
3. codesmith代码生成模板已更新，调整了命名空间，并增加了对mysql特定配置的生成。
4. 数据库备份中提供了一个MYSQL建库脚本。
应用程序框架交流QQ群1：386092459（已满）
应用程序框架交流QQ群2：376124781
EasyUi交流QQ群：157809322
本来准备只用一篇来完成本文，不过太忙了，只有分几次来写，希望各位见谅，下次更新的时间会比较长。
标签：
原文地址：http://www.cnblogs.com/xiadao521/p/4529508.html
