三层架构

三层架构

最近都是在调试公司的项目，测试数据，也没有学什么新的技术要点，但是今天要分享的是一个架构，其实在调试项目中也可以学到不一样的东西，这些知识都是很细微的东西，今天讲的是架构，当然我虽然是调试别人公司的项目，但是我也不可以截图出来说明白的，毕竟这并没有得到别人老板的允许，随便就把别人的东西拿出来分享是不合理的，当然我也会借鉴一下。

其实三层架构这种对开发人员来说已经是司空见惯了，如果不是什么大型的项目或者是超小型的项目外，可能这种架构是很适合所有人的，我为什么会讲这个是因为它和我现在调试的这个项目很相似，所以我觉得可以分享一下的。

下面有一个是对比图，这个对比图是很容易理解的，对于初学者来说，这个对比图是有很大的帮助的。

图一

如图一所示：

1.数据库就比如像我们的猪圈，毕竟我们知道猪是分很多种的，并且所有的猪都会有序的按地区，编号，放在不同的猪栏里面

2.数据访问层DAL好比如屠宰场，按流程来说的话，我们就应该把猪从猪圈中取出来进行（处理）屠杀，按照要求取出相应的部分（字段），或者进行归类整理（统计），形成整箱整箱的猪肉（数据集），传送给食品加工厂（业务逻辑层BLL），

3.业务逻辑层BLL好比如食品加工厂，将猪肉经过各种步骤加工后形成各种可以食用的食品（业务处理）

4. WEB好比商场，将食品包装成漂亮的可以销售的产品，展现给顾客（UI表现层）。

5.业务实体类Model就好比猪肉，无论是哪个厂（层）各个环节传递的都是猪肉，猪肉在这里起到了贯穿整个过程。

6.通用类库Common相当于工具厂里面工人使用的各种工具，为各个厂（层）提供了诸如杀猪刀，绳子，剪刀，包装箱，工具车等，大家都可以共用的常用工具（类），其实每个部门本来是可以自己制作的工具的，但是你们可以想象一下，如果每个人都一条龙的自己做，不但这样的效率会很低而且显不专业，因此就有人开了这样专门的工厂来制作这些工具，提供给各个工厂，有了这样的分工，这样他们就可以安心的做一件事情了。

以上对比其实就是生活中的很多东西联系在一起的了，这些都是需要我们自己去理解的。

如下我现在的图，因涉及到其他的问题，所以不过展示

你们可以看到上图中的标记，肯定会有人问那业务实体类Modul去哪里的了，其实我这连接的是别人的服务器，所以我只要从缓冲流中调用我需要的数据就可以了。

比如该用存储过程实现业务逻辑，就不用强制使用代码来实现，因为有些逻辑使用代码来实现，无论在开发时间，代码量，并发处理，性能上都与存储过程处理没法比；在需要使用ADO.NET 来执行SQL语句时，就不会为了统一框架底层调用方法，强制使用SubSonic插件相关方法来实现，如果你看到这种代码心里很不舒服的话，那只能说我们不在同一个频道上，对于这种实用型开发者来说，所追求的编辑模式方向可能与你不同

下图是本框架的扩展结构，以后的章节重点讲解的是红框框住的几个项目，详细讲述本框架底层框架构成是怎么搭建的，指导初学者们一步步搭建好自己的框架架构，注：网上借鉴的框架图

对比前面的三层架构，大家可能会很奇怪，怎么没有看到Model层的？这是因为我们使用的SubSonic3.0插件所附带的效果

这是很相似的一个框架图，就是插件化用的不一样而已，所以下面就讲一下各个层之间的调用说明

1. Solution.Common,主要存放系统调用到各种常用的工具函数，给其他所有层调用。
2. SubSonic.Core,SubSonic3.0插件码，主要负责与数据库进行交互，将业务转换成相应的SQL语句，对数据库进行各种增删，查，改等操作；
3. Solution.DataAccess,主要存放T4模板生成的业务实体Model，数据库表结构，业务实体常用函数，存储过程调用函数，以及已经封装好的各种数据库操作函数和ADO.NET数据库执行函数；
4. Solution.Logic.Managers,主要存放各种业务逻辑函数，其中SubSonic文件夹里的文件是由T4模板自动成的常用逻辑函数（会将UI层所要用到80%以上的函数自动生成出来）。这些逻辑函数主要是接收UI层的操作命令与参数，进行逻辑运算和处理后，提交给Solution.DataAccess层来处理，以实现对数据库表记录的增，删，查，改等操作；
5. Solution.Web.Managers层是UI层，用来展示 管理系统各个页面与功能，主要实现和用户的交互，接收用户请求或展示用户请求的数据结果。

总结：以上就是简单三层架构，可能写的有点简陋并且可能并不适用于所有人，但是这样的架构也算是简单明了的了。