三层架构
最近都是在调试公司的项目,测试数据,也没有学什么新的技术要点,但是今天要分享的是一个架构,其实在调试项目中也可以学到不一样的东西,这些知识都是很细微的东西,今天讲的是架构,当然我虽然是调试别人公司的项目,但是我也不可以截图出来说明白的,毕竟这并没有得到别人老板的允许,随便就把别人的东西拿出来分享是不合理的,当然我也会借鉴一下。
其实三层架构这种对开发人员来说已经是司空见惯了,如果不是什么大型的项目或者是超小型的项目外,可能这种架构是很适合所有人的,我为什么会讲这个是因为它和我现在调试的这个项目很相似,所以我觉得可以分享一下的。
下面有一个是对比图,这个对比图是很容易理解的,对于初学者来说,这个对比图是有很大的帮助的。
图一
如图一所示:
1.数据库就比如像我们的猪圈,毕竟我们知道猪是分很多种的,并且所有的猪都会有序的按地区,编号,放在不同的猪栏里面
2.数据访问层DAL好比如屠宰场,按流程来说的话,我们就应该把猪从猪圈中取出来进行(处理)屠杀,按照要求取出相应的部分(字段),或者进行归类整理(统计),形成整箱整箱的猪肉(数据集),传送给食品加工厂(业务逻辑层BLL),
3.业务逻辑层BLL好比如食品加工厂,将猪肉经过各种步骤加工后形成各种可以食用的食品(业务处理)
4. WEB好比商场,将食品包装成漂亮的可以销售的产品,展现给顾客(UI表现层)。
5.业务实体类Model就好比猪肉,无论是哪个厂(层)各个环节传递的都是猪肉,猪肉在这里起到了贯穿整个过程。
6.通用类库Common相当于工具厂里面工人使用的各种工具,为各个厂(层)提供了诸如杀猪刀,绳子,剪刀,包装箱,工具车等,大家都可以共用的常用工具(类),其实每个部门本来是可以自己制作的工具的,但是你们可以想象一下,如果每个人都一条龙的自己做,不但这样的效率会很低而且显不专业,因此就有人开了这样专门的工厂来制作这些工具,提供给各个工厂,有了这样的分工,这样他们就可以安心的做一件事情了。
以上对比其实就是生活中的很多东西联系在一起的了,这些都是需要我们自己去理解的。
如下我现在的图,因涉及到其他的问题,所以不过展示
你们可以看到上图中的标记,肯定会有人问那业务实体类Modul去哪里的了,其实我这连接的是别人的服务器,所以我只要从缓冲流中调用我需要的数据就可以了。
比如该用存储过程实现业务逻辑,就不用强制使用代码来实现,因为有些逻辑使用代码来实现,无论在开发时间,代码量,并发处理,性能上都与存储过程处理没法比;在需要使用ADO.NET 来执行SQL语句时,就不会为了统一框架底层调用方法,强制使用SubSonic插件相关方法来实现,如果你看到这种代码心里很不舒服的话,那只能说我们不在同一个频道上,对于这种实用型开发者来说,所追求的编辑模式方向可能与你不同
下图是本框架的扩展结构,以后的章节重点讲解的是红框框住的几个项目,详细讲述本框架底层框架构成是怎么搭建的,指导初学者们一步步搭建好自己的框架架构,注:网上借鉴的框架图
对比前面的三层架构,大家可能会很奇怪,怎么没有看到Model层的?这是因为我们使用的SubSonic3.0插件所附带的效果
这是很相似的一个框架图,就是插件化用的不一样而已,所以下面就讲一下各个层之间的调用说明
- Solution.Common,主要存放系统调用到各种常用的工具函数,给其他所有层调用。
- SubSonic.Core,SubSonic3.0插件码,主要负责与数据库进行交互,将业务转换成相应的SQL语句,对数据库进行各种增删,查,改等操作;
- Solution.DataAccess,主要存放T4模板生成的业务实体Model,数据库表结构,业务实体常用函数,存储过程调用函数,以及已经封装好的各种数据库操作函数和ADO.NET数据库执行函数;
- Solution.Logic.Managers,主要存放各种业务逻辑函数,其中SubSonic文件夹里的文件是由T4模板自动成的常用逻辑函数(会将UI层所要用到80%以上的函数自动生成出来)。这些逻辑函数主要是接收UI层的操作命令与参数,进行逻辑运算和处理后,提交给Solution.DataAccess层来处理,以实现对数据库表记录的增,删,查,改等操作;
- Solution.Web.Managers层是UI层,用来展示 管理系统各个页面与功能,主要实现和用户的交互,接收用户请求或展示用户请求的数据结果。
总结:以上就是简单三层架构,可能写的有点简陋并且可能并不适用于所有人,但是这样的架构也算是简单明了的了。