×

深圳网站建设—APP开发—网站制作—小程序开发_博纳网络公司

0755 -
82538016
82560826
网站制作资讯

网站建设框架使用的主流软件架构简介

文章编辑:网站建设 文章来源:深圳网站建设专栏 浏览量:

  网站建设框架使用的主流软件架构简介,随着网站建设软件应用领域的扩展和软件产品数量的激增,出现了适合各种需求的软件架构。随着软件工程技术的快速发展,软件架构也在不停地演进。推动这些架构发展的力量是编程思想的进步及新技术和框架的产生。网站建设公司由于篇幅的原因,本节不能详细介绍这些架构及其发展过程,只能集中介绍几个与深圳网站建设公司案例配套的演示项目相关的架构,它们也是目前主流的软件架构,如分层架构、REST架构和微服务架构等。
网站建设关于分层架构
  分层架构(Layered Architecture)是目前为止最为常用的架构,也是最符合软件公司组织结构的架构。分层架构的思想很简单,把系统分解为若干个层(Layer),每一层的逻辑代码都具有高内聚的特点,每层之间只能通过抽象的接口进行访问,降低了层之间的耦合性。为了更合理地管理依赖关系,每一层只能访问和它相邻的低级别的层,并且只能向高一级的层提供服务,如图3.5所示。
从图3.5中可以看出,分层架构简单、易懂,大部分程序设计人员都可以理解。这种架构的程序开发和测试都比较容易,在测试时每一层可以单独进行,对下一层的依赖可以通过模拟获取。网站建设使用分层架构因为简单、易用,被应用到大量的系统开发中。分层架构在系统的模块化和低耦合、高内聚方面也起到了很好的作用。分层架构是一种架构风格,在其应用中约束了层之间的依赖和调用,每一层相当于上一层的服务器或基础设施,而更深的层则完全隐身,并且不允许跨层调用,也不允许下层调用上层。下层对上层的调用只能通过中介模式。
  在分层架构风格中,层之间的隔离和约束为开发和测试提供了有力的保障,并有效地提高了软件产品的质量。层之间的调用通过抽象接口,避免了层之间的类型泄漏和相互依赖。通过层的隔离,保证了可修改性、可移植性和可重用性。
分层架构风格在实际使用中可以选择多种架构模式。最常用的模式是4层架构模式。这种模式把系统分解成4层,分别是UI层、应用程序层、业务逻辑层(或领域模型层)和数据访问层。4个层的关注点各不相同。
UI层关注如何和用户交互。应用程序层关注如何提供系统的功能,它直接为UI层服务,为UI层获取需要显示的数据,以及解释来自UI层的命令。业务逻辑层是系统的核心层,负责描述和解决特定领域的问题。数据访问层把业务逻辑层中的对象状态保存到数据库中,并在需要时读取出来。4层架构模式如图3.6所示。
4层架构模式是分层架构风格最简单的应用,用十分简单的方式实现了分层架构风格的约束。但是由于这种架构模式自身的弊端,并没有被大规模应用。在该模式中,上层对下层的引用虽然以抽象的接口解耦,但是在描述返回数据值时十分困难。这时可以使用单独的数据模型定义返回数据的类型。以UI层和应用程序层为例,加入数据模型后的架构如图3.7所示。
加入数据模型以后,UI层和应用程序层都会引用数据模型,这样就解决了返回数据类型的问题。当然,如果数据模型能够贯穿整个系统分层,那么这个数据模型可以被所有层引用,从而成为所有层共享的数据模型。
数据模型的加入解决了部分问题,但同时也带来了两个问题。首先,数据模型的本意是定义各层之间需要传递的数据,在业务逻辑层用于描述问题和解决问题的是领域对象。当从数据访问层获取数据模型以后,还要提供一个数据模型到领域对象的双向转换。如果直接把领域模型写在数据模型中会带来更大的麻烦,这—点在后面介绍领域模型时会详细讨论。
第二个问题来源于依赖。数据模型看似降低了依赖,甚至有的项目为了降低依赖,会把服务接口也定义在数据模型中,这其实是分层模式本身的问题。数据模型和接口都可以定义在单独的包中,它们的定义都依赖于上层的需求。也就是说,下层的实现依赖于上层的定义,不管它们是否定义在单独的包中,上层都会依赖于下层的实现而定义,这时就在上下两层间形成了双向依赖,这违背了依赖倒置原则(Dependence Inversion Principle),即依赖于抽象而不依赖于实现,如图3.8所示。
解决这个问题的方案是在层之间引入依赖注入。依赖注入是实现控制翻转的一种形式,主要方法是通过依赖注入容器,实现层之间的解耦。注入依赖主要是为了解除上层对下层的引用依赖,下层保持对上层接口和数据类型的抽象依赖,而上层对下层的引用依赖被转移到容器中。简单地说,上层的调用接口仍然定义在上层,当上层需要使用下层实现的对象时,直接从容器中获取即可,如图3.9所示。
当引入依赖注入后,下层的服务接口及上层需要的数据类型都定义在上层,上层不引用下层,而下层引用上层。其实这时候上下层已经互换了,原来的下层已经变成了上层。在传统的4层架构中,数据访问层作为实现的下层,在加入依赖注入后已经变成了上层。
当数据访问层变为上层以后,就可以为其他各层提供具体的服务,只是在各个层中需要定义服务的接口。而应用程序层和业务逻辑层也不需要保持引用依赖。同时,数据访问层提供了其他层的实现接口,也就成了其他层的基础设施。UI层负责在初始化时把基础设施层的实现对象注入容器中。引入依赖注入的4层架构模式如图3.10所示。
分层架构是一个简洁、易用的架构模式,但是在很多项目中,由于开发者对分层架构的错误理解,造成了各层之间错误的依赖关系。各层之间错误的依赖关系会使系统的稳定性降低,只有使用依赖注入技术,才能真正解决分层架构的依赖问题。好了,深圳网站建设公司本文关于“网站建设框架使用的主流软件架构简介”的建站经验就分享到这里,谢谢关注,博纳网络编辑整理。

当前文章链接:/construction/solution/14653.html
如果您觉得案例还不错请帮忙分享:

[声明]本网转载网络媒体稿件是为了传播更多的信息,此类稿件不代表本网观点,本网不承担此类稿件侵权行为的连带责任。故此,如果您发现本网站的内容侵犯了您的版权,请您的相关内容发至此邮箱【qin@198bona.com 】,我们在确认后,会立即删除,保证您的版权。

相关案例推荐