话说三层
现在分层架构的思想真是深入人心了感觉,比如最近我们用VB6在作的一个小项目,虽然VB6不是一个纯粹的OO的语言,在这个项目中我们仍然使用了流行的三层架构:)
首先重温一下在Asp.Net项目中经常使用的三层架构。
我们用三层结构主要是使项目结构更清楚,分工更明确,有利于后期的维护和升级.
三层结构包含:表示层(USL),业务逻辑层(BLL),数据访问层(DAL)
1:数据数据访问层:主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,具体为业务逻辑层或表示层提供数据服务.
2:业务逻辑层:主要是针对具体的问题的操作,也可以理解成对数据层的操作,对数据业务逻辑处理,如果说数据层是积木,那逻辑层就是对这些积木的搭建。
3:表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx, 如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。
具体的区分方法
1:数据数据访问层:主要看你的数据层里面有没有包含逻辑处理,实际上他的各个函数主要完成各个对数据文件的操作。而不必管其他操作。
2:业务逻辑层:主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。
3:表示层:主要对用户的请求接受,以及数据的返回,为客户端提供应用程序的访问。
ASP.NET中的三层结构说明
完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层.否则你的应用是不是多层结构,或者说是层结构的划分和组织上是不是有问题就很难说.
在谈一下在我们目前这个vb项目中我们自己建立的三层架构,由于VB使用的很少,可能当前的认识也有偏差的地方。
该项目中建立一个工程组,其中包含4个工程,其中一个存放用户控件,见下图:
![](https://www.cnblogs.com/images/cnblogs_com/s1ihome/projSample.gif)
TBI这个工程,本来建立的意图是作为业务逻辑层,但是其实际作用相当于数据访问层,对数据库的操作都放在了这个里面。而业务逻辑层则是存在于frm本身的代码中。
DataAccess工程中仅存放了两个类模块文件,封装了对数据库的操作,非常类似于SqlHelper.Cs。
而实际在我参与的.net项目中,感觉业务逻辑层的功能似乎也都遭遇了淡化,而和aspx.cs文件混合在了一起,至于其优劣,还是要具体情况具体分析吧。
首先重温一下在Asp.Net项目中经常使用的三层架构。
我们用三层结构主要是使项目结构更清楚,分工更明确,有利于后期的维护和升级.
三层结构包含:表示层(USL),业务逻辑层(BLL),数据访问层(DAL)
1:数据数据访问层:主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,具体为业务逻辑层或表示层提供数据服务.
2:业务逻辑层:主要是针对具体的问题的操作,也可以理解成对数据层的操作,对数据业务逻辑处理,如果说数据层是积木,那逻辑层就是对这些积木的搭建。
3:表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx, 如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。
具体的区分方法
1:数据数据访问层:主要看你的数据层里面有没有包含逻辑处理,实际上他的各个函数主要完成各个对数据文件的操作。而不必管其他操作。
2:业务逻辑层:主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。
3:表示层:主要对用户的请求接受,以及数据的返回,为客户端提供应用程序的访问。
ASP.NET中的三层结构说明
完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层.否则你的应用是不是多层结构,或者说是层结构的划分和组织上是不是有问题就很难说.
在谈一下在我们目前这个vb项目中我们自己建立的三层架构,由于VB使用的很少,可能当前的认识也有偏差的地方。
该项目中建立一个工程组,其中包含4个工程,其中一个存放用户控件,见下图:
![](https://www.cnblogs.com/images/cnblogs_com/s1ihome/projSample.gif)
TBI这个工程,本来建立的意图是作为业务逻辑层,但是其实际作用相当于数据访问层,对数据库的操作都放在了这个里面。而业务逻辑层则是存在于frm本身的代码中。
DataAccess工程中仅存放了两个类模块文件,封装了对数据库的操作,非常类似于SqlHelper.Cs。
而实际在我参与的.net项目中,感觉业务逻辑层的功能似乎也都遭遇了淡化,而和aspx.cs文件混合在了一起,至于其优劣,还是要具体情况具体分析吧。