分层架构根据相关职责将应用程序模块切割为多个层次，那么应用程序框架本身还要不要进行层次划分？随着对应用程序框架的理解加深，以及项目复杂度的提升，为应用程序框架分层就显得很有必要，它将影响你如何创建VS解决方案。
在刚开始建立应用程序框架时，你首先会想到的是把技术方面的东西抽取出来，放到专门的文件夹，但你很快发现建立一个独立的.Net类库更加方便。你平时会把需要用到的东西封装成Helper扔进去，有时候也会引用一些第三方的程序集。随着日积月累，这个类库逐步变得丰富，同时杂草也在滋长，很显然这时候你还没有依赖管理的概念。
一个新项目准备启动，你开始搭建环境，当你引入框架类库时，发现有一些根本用不上的第三方dll也必须引用进来，比如Microsoft.Office.Interop.Word.dll，你感觉到你的框架类库完全就是一个大杂烩，必须拆分才行，此时，说明你开始察觉到依赖的存在。
如何拆分这些依赖呢？需要创建更多的类库，把依赖性较强的部分分离出来。怎样看出依赖性的强弱？首先考虑是否需要引入.Net Framework之外的程序集，如果需要，肯定是强依赖，这主要是指第三方框架。其次考虑是否需要特定环境支持，比如数据库操作，Web操作，Windows操作，这些操作都依赖性很强，放到单独的程序集更好。
随着应用程序框架的持续积累，框架程序集的数量也在增长，现在你的解决方案每次编译一下，好几分钟动弹不得，虽然你多次恳求老板换台更快的电脑，这样工作效率更高，不过你的老板是个聪明人，笑着告诉你“嘿嘿，你小子的速度都超过电脑了”。电脑换不成，只好另想办法，你发现为应用程序框架建立一个独立的解决方案可以显著减少VS编译项目的时间。把应用程序框架与项目分离之后，会发现框架和项目的职责也更加清晰。当下一个项目来临时，只需要引入相关的DLL即可。
在进行技术积累的同时，你的项目经验也在不断增强，发现很多业务知识可以抽取出来，根据之前的经验，你决定为业务框架专门创建一个VS解决方案。刚开始可能只有一些通用业务类型，比如地址。后面把业务领域一些专业的知识也封装进去，并创建了不同的程序集。除此之外，你还把第三方的接口也封装起来，像支付接口，充值接口，商城接口，酒店预订接口。
可以看到，根据逻辑分类和依赖关系，至少可以把应用程序框架分成技术和业务两大类，每个大类还会继续划分，示意图如下。
新手更倾向于少量的类库，而老手则会根据依赖创建大量类库。至于具体创建多少个解决方案和程序集，也完全根据你的习惯而定。
.Net应用程序框架交流QQ群: 386092459，欢迎有兴趣的朋友加入讨论。