码迷,mamicode.com
首页 > 其他好文 > 详细

应用程序框架实战三十八:项目示例VS解决方案的创建(一)

时间:2015-05-26 06:47:03      阅读:151      评论:0      收藏:0      [点我收藏+]

标签:

  进行项目开发的第一步,是创建出适合自己团队习惯的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项目都是基础设施层的一个组成部分。

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

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

 

(未完待续…

代码更新

  1. 更新了js中的一些Bug
  2. 由于项目上需要使用MYSQL,最近几天摸索了EF操作MYSQL,遇到的一些障碍已解决,特将解决方案放出,供使用MYSQL的同学参考。

    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群

  应用程序框架交流QQ群1:386092459(已满) 

  应用程序框架交流QQ群2:376124781 

  EasyUi交流QQ群:157809322 

源码下载:(下载时顺手推荐)

框架源码

项目示例源码

数据库备份

Codesmith生成器模板

备注

  本来准备只用一篇来完成本文,不过太忙了,只有分几次来写,希望各位见谅,下次更新的时间会比较长。

应用程序框架实战三十八:项目示例VS解决方案的创建(一)

标签:

原文地址:http://www.cnblogs.com/xiadao521/p/4529508.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!