真正接触前后端分离模式也就几个月的时间。本文属于自己对前后端分离模式的一些总结,主要来源于针对之前的后端做数据渲染与分离模式的一些对比。近期会针对一些常见的开发模式做一些分享,如果对你有帮助,给个关注吧!!!
前后端分离从端口划分就是将浏览器、客户端分为前端,提供真实服务的软件就成为后端。从开发语言的角度划分后端的编程语言和前端的编程语言,例如Java是做后端真实数据服务的,JavaScript、html是做前端业务数据的展现与用户行为操作的。
A.为什么会出现前端和后端分离模式,这得从有前后端分离开发模式之前的开发模式说起。我们先看下面两张图。
第一张图是非前后端分离。
1.首先,我们通过图片可以看出,一个项目的开始从产品经理,其次是设计工程师,其次是前端开发工程师......最后才是运维工程师进行项目部署。这样一个项目才算的上真正的开发完成了。
2.这样的开发模式全程是一个串行的模式,从外观就有点像一条龙服务的模式,后者依赖于前者。用编程中的一个词语就是,高藕和。
第二张图是前后端分离。
1.首先,我们通过这张图片可以看出,一个项目的开始同样是从产品经理,接着就是设计工程师负责。
2.最重要的一点,我们看设计工程师在负责的同时,后端工程师和前端工程师都在同样的进行开发,这样三者是处于并行进行。
3.然后设计工程师设计完之后,交付给前端工程师,后端开发工程师完成之后可以和前端工程师做对接。
4.这三者完成之后,接下来就是测试工程师,最后同样的是运维工程师负责。这样一个项目才算的上真正的开发完成了。
5.通过这种模式,我们不难看出,在产品经理完成之后,不再是单独的设计工程师完成之后交给前端工程师,然后在交给后端工程师,而是三者可以处于并行的一个状态。
B.上面谈完了,我们接下来分析总结一下非前后端分离模式的缺点。
1.开发效率低。
通过上面的图一,我们看的出每一个环节都依赖进行,难免延长了开发周期。
2.整个团队的协作耦合度高。
环节层层依赖。如果某个环境进行了修改,其他的环境就得收到影响。
3.团队容易甩锅。
当项目出现问题之后,团队成员很容易将一些责任推到其他的环节上面。
4.难以处理越来越复杂的业务。
随着现目前的业务发展趋势,业务也越来越复杂。例如,一些页面交互效果,数据处理。传统的模式很难支持这样的业务场景。通过前后端分离,前端负责对应的交互业务,后端负责数据的处理。
5.使得代码的耦合度更高。
这里可以从一种软件设计模式来分析。那就是MVC模式,模型层(M)负责数据库层面的操作,控制层(C)负责处理逻辑,视图层(V)负责数据渲染。这是一种很不错的软件设计模式。但在不做到严格规范的情况下,仍有很多的程序开发者,在控制层C输出一些视图层V的业务代码,这样的代码似的代码的耦合度更高,同时也难以维护。
综上B点弊端,我们不难分析出前后端分离的一些好处了。
1.提高开发效率。
2.降低的软件设计的耦合度。不管是前端还是后端,都可以针对不同的端,实现一些工程化的东西。
3.提高了处理复杂业务的能力。后端可以只专注后端业务,前端可以专注于前端的业务。
1.团队沟通成本。
每个环节都需要保证沟通、协商好,否则很容易导致团队混乱,因此前后端分离模式对团队协调也是有着较高的要求。
2.不利于搜索引擎抓取。
因为搜索引擎看的是html源码,不能执行js,也就无法获取js动态从ajax抓的内容。
3.项目维护成本。
前后端分离,后端的代码和前端的代码都需要单独部署。在开发中也需要针对开发需求部署不同的环境。
4.增加繁杂的配置。
前后端分离,需要设置跨域一系列的其他操作。同时也会针对前后端的一些监控处理。都无疑增加了工作量。
所谓的前后端并不是单纯的指前端工程师负责的内容和后端工程师负责的内容之间可以独立进行。总体归纳如下几点:
1.产品设计
2.设计
3.前端开发
4.后端开发
5.测试
6.部署
这几个环节,其实很多都可以并行运行。
1.例如,在产品设计好之后,能够具体确定哪些功能,前后端工程师可以协商接口、接口参数等需要对接的内容,设计师可以同时负责设计。
2.当定义好了项目的一些规范,前后端的开发人员在开发的过程中,可能会需要一些模拟数据,这时候后端开发人员并未开发出对应的接口,那怎么办呢?就可以事先使用mock模拟一些数据,供前端人员调用,后端人员开发完成之后,前端直接调用真实数据。
3.在前后端开发过程中,测试人员可以针对前端人员开发的功能进行前端调试,例如UI还原、用户交互缺陷等。测试人员也可以针对后端开发人员的接口进行数据调试。
4.最后运维工程师在前端和后端工程师开发过程中,可以针对前端的环境进行一些列的搭建,也可以针对后端的环境进行一系列的搭建。待项目开发、测试完成就直接部署,而不是等到开发、测试完成之后才来从0开始部署。
本文可转载,需注明出处(公号:卡二条的技术圈)
单例模式是我们开发中一个非常典型的设计模式,js单例模式要保证全局只生成唯一实例,提供一个单一的访问入口,单例的对象不同于静态类,我们可以延迟单例对象的初始化,通常这种情况发生在我们需要等待加载创建单例的依赖。
工厂模式下的对象我们不能识别它的类型,由于typeof返回的都是object类型,不知道它是那个对象的实例。另外每次造人时都要创建一个独立的person的对象,会造成代码臃肿的情况。
建造者模式:是将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。工厂类模式提供的是创建单个类的模式,而建造者模式则是将各种产品集中起来进行管理,用来创建复合对象
主要涉及知识点: HTML与XHTML,HTML与XHTML的区别,DOCTYPE与DTD的概念,DTD的分类以及DOCTYPE的声明方式,标准模式(Standard Mode)和兼容模式(Quircks Mode),标准模式(Standard Mode)和兼容模式(Quircks Mode)的区别
JavaScript中常见的四种设计模式:工厂模式、单例模式、沙箱模式、发布者订阅模式
javascript 策略模式的定义是:定义一系列的算法,把它们一个个封装起来,并且使它们可以相互替换。 策略模式利用组合,委托等技术和思想,有效的避免很多if条件语句,策略模式提供了开放-封闭原则,使代码更容易理解和扩展, 策略模式中的代码可以复用。
javascript观察者模式又叫发布订阅模式,观察者模式的好处:js观察者模式支持简单的广播通信,自动通知所有已经订阅过的对象。存在一种动态关联,增加了灵活性。目标对象与观察者之间的抽象耦合关系能够单独扩展以及重用。
熟悉 Vue 的都知道 方法methods、计算属性computed、观察者watcher 在 Vue 中有着非常重要的作用,有些时候我们实现一个功能的时候可以使用它们中任何一个都是可以的
我觉得聊一下我爱用的 JavaScript 设计模式应该很有意思。我是一步一步才定下来的,经过一段时间从各种来源吸收和适应直到达到一个能提供我所需的灵活性的模式。让我给你看看概览,然后再来看它是怎么形成的
在围绕设计模式的话题中,工厂这个词频繁出现,从 简单工厂 模式到 工厂方法 模式,再到 抽象工厂 模式。工厂名称含义是制造产品的工业场所,应用在面向对象中,顺理成章地成为了比较典型的创建型模式
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!