编程路上三层始出现
2015-12-31 21:11
344 查看
三层架构:三层是一个笼统的概念,是在逻辑上的划分,我们在设计复杂的程序时,为了使我们维护更加的简单,提出的一种概念。它分为三层,两个直接,一个中转。只要逻辑够复杂就把代码放到B层,只要数据访问了就把代码放到D层。U层做的好看一点,让人用起来要舒服。
U层:即用户界面层,直接与用户打交道的。在代码中没有商业业务逻辑,没有或有少量的SQL,存储过程语句。而且这些语句用不着修改。
B层:即业务逻辑层,处理业务上的复杂逻辑,主要进行业务上的逻辑判断。是整个系统的核心,和我们的需求是直接相关的。它连接了U层和D层。在设计系统时,我们就是根据这块来进行设计的。
D层:即数据访问层,注意它是数据访问,而不是数据库本身。它是直接对数据库进行增删改查的。把结果返给B层。
我对三层架构优点的理解:分工合作,开发效率高,每个人可以专注搞自己的一层;由于每层相互独立,所以只要接口搭配好了,每层都可以替换。相比VB版的代码,三层的代码要简单,结构清晰;每层代码都可以复用,典型面向对象的特点。
缺点:三层相互传递信息,降低了系统的性能,不过对机房来说根本看不出来。导致级联的修改,也就是说,给U层添加一个功能,相应的B层和D层也要修改。
了解三层的大概了,那么怎么着才是三层呢?很简单,三层的优点做到了,那就是三层喽。简单说一下:
U层只有少量的或没有SQL语句和存储过程,且这些语句都不会修改;要求D层可以移植到其他的项目中;各层的模块可以在其它服务器上运行。U层只能作为一个外壳,不能包含BizLogic(商务逻辑)的处理过程。
设计时从B层出发,不是从U层出发,B层在API(应用程序)上应该实现所有BizLogic;D层是简单的SqlHelper(封装好的数据库操纵组件)也好,还是带有Mappitng过的Clases(ORM对象关系映射,和数据库有关)也好,应该在一定的抽象程度上做到系统无关;不管使用COM+(可能是面向组件编程)还是Remoting(一种分散式程序设计)还是WebService(一种分散式程序设计)之类的远程技术,不管部署的时候是不是真的分别部署到不同的服务器上,最起码在设计的时候要做这样的考虑,更远的,考虑多台服务器通过负载均衡做集群。感觉系统特别大了,三层正好分担系统的压力。
还有另一个问题:说是三层,可明明在敲代码有个实体层,那这是个什么东西类。看完三层的一大堆后,我的理解时:它不属于三层,可没了它我们在设计时虽然可以实现,但是忒麻烦。可以根据代码可以观察下实体层。它里面就是包含了大量的信息,基本没有什么方法实现;它在三层交换信息时起到了作用;它和数据库的设计比较契合。所以说实体层不属于三层,它压根就没有什么功能实现,换言之没了你这个系统照样存在。那为什么又麻烦呢?在三层相互交换信息时,我们需要参数,假设你传递的是参数,那么整个系统那么大,大量的参数就把你搞晕了。另一个就是传参的个数了,一个两个,还好说,要是一大堆呢。所以说没了实体层就是麻烦啊,所以感叹前辈的高明啊,为我们的设计之路铺好了那么多。实体层:对那么多参数的分类,把参数封装到一块,用到哪个参数,再把它给点出来。
上面我提到了三层架构了,其实我压根就不知道什么是架构,架构啥玩意呢。一般人还真搞不懂。考虑到读者,也考虑到咱的文采请看下篇吧。
U层:即用户界面层,直接与用户打交道的。在代码中没有商业业务逻辑,没有或有少量的SQL,存储过程语句。而且这些语句用不着修改。
B层:即业务逻辑层,处理业务上的复杂逻辑,主要进行业务上的逻辑判断。是整个系统的核心,和我们的需求是直接相关的。它连接了U层和D层。在设计系统时,我们就是根据这块来进行设计的。
D层:即数据访问层,注意它是数据访问,而不是数据库本身。它是直接对数据库进行增删改查的。把结果返给B层。
我对三层架构优点的理解:分工合作,开发效率高,每个人可以专注搞自己的一层;由于每层相互独立,所以只要接口搭配好了,每层都可以替换。相比VB版的代码,三层的代码要简单,结构清晰;每层代码都可以复用,典型面向对象的特点。
缺点:三层相互传递信息,降低了系统的性能,不过对机房来说根本看不出来。导致级联的修改,也就是说,给U层添加一个功能,相应的B层和D层也要修改。
了解三层的大概了,那么怎么着才是三层呢?很简单,三层的优点做到了,那就是三层喽。简单说一下:
U层只有少量的或没有SQL语句和存储过程,且这些语句都不会修改;要求D层可以移植到其他的项目中;各层的模块可以在其它服务器上运行。U层只能作为一个外壳,不能包含BizLogic(商务逻辑)的处理过程。
设计时从B层出发,不是从U层出发,B层在API(应用程序)上应该实现所有BizLogic;D层是简单的SqlHelper(封装好的数据库操纵组件)也好,还是带有Mappitng过的Clases(ORM对象关系映射,和数据库有关)也好,应该在一定的抽象程度上做到系统无关;不管使用COM+(可能是面向组件编程)还是Remoting(一种分散式程序设计)还是WebService(一种分散式程序设计)之类的远程技术,不管部署的时候是不是真的分别部署到不同的服务器上,最起码在设计的时候要做这样的考虑,更远的,考虑多台服务器通过负载均衡做集群。感觉系统特别大了,三层正好分担系统的压力。
还有另一个问题:说是三层,可明明在敲代码有个实体层,那这是个什么东西类。看完三层的一大堆后,我的理解时:它不属于三层,可没了它我们在设计时虽然可以实现,但是忒麻烦。可以根据代码可以观察下实体层。它里面就是包含了大量的信息,基本没有什么方法实现;它在三层交换信息时起到了作用;它和数据库的设计比较契合。所以说实体层不属于三层,它压根就没有什么功能实现,换言之没了你这个系统照样存在。那为什么又麻烦呢?在三层相互交换信息时,我们需要参数,假设你传递的是参数,那么整个系统那么大,大量的参数就把你搞晕了。另一个就是传参的个数了,一个两个,还好说,要是一大堆呢。所以说没了实体层就是麻烦啊,所以感叹前辈的高明啊,为我们的设计之路铺好了那么多。实体层:对那么多参数的分类,把参数封装到一块,用到哪个参数,再把它给点出来。
上面我提到了三层架构了,其实我压根就不知道什么是架构,架构啥玩意呢。一般人还真搞不懂。考虑到读者,也考虑到咱的文采请看下篇吧。
相关文章推荐
- C++11中async中future用法(一)
- PHP学习练手(十一)
- 新增的Java MapReduce API
- php 二维数组传递给 js 问题解决记录
- 如何使用java.lang.String.contains()方法
- php中二维数组如何使用
- java 枚举类型拾遗
- python删除某行
- go标准命令详解0.14 go env
- go标准命令详解0.13 go tool cgo
- go标准命令详解0.12 go tool pprof
- go标准命令详解0.11 go vet与go tool vet
- go标准命令详解0.10 go fix与go tool fix
- go标准命令详解0.9 go fmt与gofmt
- go标准命令详解0.8 go list
- go标准命令详解0.7 go test
- go标准命令详解0.6 go run
- go标准命令详解0.5 godoc
- go标准命令详解0.4 go clean
- go标准命令详解0.3 go get