应用程序框架的层次规划

分层架构根据相关职责将应用程序模块切割为多个层次,那么应用程序框架本身还要不要进行层次划分?随着对应用程序框架的理解加深,以及项目复杂度的提升,为应用程序框架分层就显得很有必要,它将影响你如何创建VS解决方案。

在刚开始建立应用程序框架时,你首先会想到的是把技术方面的东西抽取出来,放到专门的文件夹,但你很快发现建立一个独立的.Net类库更加方便。你平时会把需要用到的东西封装成Helper扔进去,有时候也会引用一些第三方的程序集。随着日积月累,这个类库逐步变得丰富,同时杂草也在滋长,很显然这时候你还没有依赖管理的概念。

一个新项目准备启动,你开始搭建环境,当你引入框架类库时,发现有一些根本用不上的第三方dll也必须引用进来,比如Microsoft.Office.Interop.Word.dll,你感觉到你的框架类库完全就是一个大杂烩,必须拆分才行,此时,说明你开始察觉到依赖的存在。

如何拆分这些依赖呢?需要创建更多的类库,把依赖性较强的部分分离出来。怎样看出依赖性的强弱?首先考虑是否需要引入.Net Framework之外的程序集,如果需要,肯定是强依赖,这主要是指第三方框架。其次考虑是否需要特定环境支持,比如数据库操作,Web操作,Windows操作,这些操作都依赖性很强,放到单独的程序集更好。

随着应用程序框架的持续积累,框架程序集的数量也在增长,现在你的解决方案每次编译一下,好几分钟动弹不得,虽然你多次恳求老板换台更快的电脑,这样工作效率更高,不过你的老板是个聪明人,笑着告诉你“嘿嘿,你小子的速度都超过电脑了”。电脑换不成,只好另想办法,你发现为应用程序框架建立一个独立的解决方案可以显著减少VS编译项目的时间。把应用程序框架与项目分离之后,会发现框架和项目的职责也更加清晰。当下一个项目来临时,只需要引入相关的DLL即可。

在进行技术积累的同时,你的项目经验也在不断增强,发现很多业务知识可以抽取出来,根据之前的经验,你决定为业务框架专门创建一个VS解决方案。刚开始可能只有一些通用业务类型,比如地址。后面把业务领域一些专业的知识也封装进去,并创建了不同的程序集。除此之外,你还把第三方的接口也封装起来,像支付接口,充值接口,商城接口,酒店预订接口。

可以看到,根据逻辑分类和依赖关系,至少可以把应用程序框架分成技术和业务两大类,每个大类还会继续划分,示意图如下。

新手更倾向于少量的类库,而老手则会根据依赖创建大量类库。至于具体创建多少个解决方案和程序集,也完全根据你的习惯而定。

应用程序框架实战