前后端完全分离的思考

网站开发历程

1、杂合模式

早期的asp开发网站时期大多是如此,
一个asp文件混合业务处理,页面显示,js动态交互;完全杂合在一起;

一个请求对应一个asp文件,业务逻辑解析,动态输出html内容。

后期的php、早期的jsp也是如此模式;

2、webform模式

这个是微软asp.net时期的一个方式,本质上是封装html为服务器控件,动态生成html及相关提交和状态保持;

前后端分离,事件触发模式;

出发点是好的,但是这个模式问题太多。

简单的问题复杂化,导致大家学习成本增加,要单独取学习下服务器控件,这个完全背离了html简单简洁的原则。

导致各种代码冗余,开发代码的灵活性也降低到不行。

随着后来无刷新ajax技术流行,微软渐渐也是放弃了这个提交submit的交互模式,尽管后来有scriptmanager等也是各种难受,

封装到最后还不如直接用html来的科学,方便。

学习成本也是标高,和底层了解html背道而驰。

慢慢的就淡出了大家的视野。

3、模板引擎模式

一套独立的模板语法,这个好多的都是独立的模板引擎(包括现在微软的razor其实也才如此,只能说mvc也是low)

大多是基于自己开发的或者统一的模板引擎,将页面显示部分独立出来到单独html文件;

这个方式的好处多了取了,方便模板的统一管理,核心业务被单独分离出去;模板只完成显示任务;

服务器端完成页面解析生成HTML内容返回给客户端,

服务器端:数据+模板语法;

(说下asp.net mvc吧,路由机制真是太死板了。这个要表扬下nancy吧,人家的灵活性真是没谁了。

mvc不再基于aspx页面的存在而是基于路由模式;

然后control的自动绑定model只能说太low,灵活性太差;增加减少字段就要重构一遍model;

view用一个集中的bag管理数据,也是难为作者了。然后就是htmlHelper了,又是服务器控件的翻版。

只能说本意是好的,如此而已。徒增加学习成本)

4、前后端完全分离模式

服务器端:完成业务逻辑处理,返回数据(json)给客户端;微服务API;

客户端:模板引擎(vue好像正火)+数据(json)

这个模式好处N多,

最大的好处就是一套API,无限终端(只要你的API服务器够强大)

a、服务器减压,显示逻辑不需要客户端组装,完全有客户端js完成;

b、一套api接口可以给各种客户端调用,app、web,gui等等;

c、客户端单独部署、api单独部署、甚至可以多前端部署;

d、业务逻辑服务器,相对独立的模块可以单独部署开发;

e、独立的认证服务器,基于auth2.0模式;单点登录,统一认证;方便第三方调用集成;用户+权限;

f、方便版本升级,多版本并存,请求路径修改就好;API接口统一;

g、升级维护成本降低,界面只是完成显示,修改不会影响到业务逻辑;要知道大家对美的要求真是日新月异。

h、方便单元测试,mvc模式解决了这个问题;

总结:

多终端时代,无疑微服务API是最科学的选择。

服务器端渐渐只完成必须完成的工作,能不做的都分配到客户端部分完成,这样才是最好的选择。

原文地址:https://www.cnblogs.com/Running_Zhang/p/11385562.html

时间: 2024-10-10 10:49:09

前后端完全分离的思考的相关文章

dotnet core webapi +vue 搭建前后端完全分离web架构

架构 服务端采用 dotnet core  webapi 前端采用: Vue + router +elementUI+axios 问题 使用前后端完全分离的架构,首先遇到的问题肯定是跨域访问.前后端可能不在同个server上,即使前后端处在同个server上,由于前后端完全分离, 前后端使用的端口号也可能是不一样的,所以必须解决跨域访问. 具体实现 服务端 服务端使用的dotnetcore +webapi架构,支持cors非常简单,只要引入Microsoft.AspNetCore.Cors 组件

前后端分离的思考与实践(六)

原文出处: 淘宝UED - 筱谷 Nginx + Node.js + Java 的软件栈部署实践 起 关于前后端分享的思考,我们已经有五篇文章阐述思路与设计.本文介绍淘宝网收藏夹将 Node.js 引入传统技术栈的具体实践. 淘宝网线上应用的传统软件栈结构为 Nginx + Velocity + Java,即: 在这个体系中,Nginx 将请求转发给 Java 应用,后者处理完事务,再将数据用 Velocity 模板渲染成最终的页面. 引入 Node.js 之后,我们势必要面临以下几个问题: 技

dotnet core webapi +vue 搭建前后端完全分离web架构(一)

摘要: 架构 服务端采用 dotnet core  webapi   前端采用: Vue + router +elementUI+axios            问题 使用前后端完全分离的架构,首先遇到的问题肯定是跨域访问. 架构 服务端采用 dotnet core  webapi 前端采用: Vue + router +elementUI+axios 问题 使用前后端完全分离的架构,首先遇到的问题肯定是跨域访问.前后端可能不在同个server上,即使前后端处在同个server上,由于前后端完

基于Spring Boot架构的前后端完全分离项目API路径问题

最近的一个项目采用前后端完全分离的架构,前端组件:vue + vue-router + vuex + element-ui + axios,后端组件:Spring Boot + MyBatis.之所以这样做是为了考虑后端水平扩容的便利性,在部署的时候完全可以将前后端彼此独立部署,前端部署可以直接使用诸如Nginx这样的高性能Web服务器. 前端需要知道它所访问的后端服务器IP地址才能访问到数据,但是如果将IP地址硬编码在前端代码中的话,在部署的时候会存在一个问题:当服务器端IP地址变化之后必须重

前后端分离的思考与实践(一)

原文出处: 淘宝UED - 常胤 也谈基于NodeJS的全栈式开发(基于NodeJS的前后端分离) 前言 为了解决传统Web开发模式带来的各种问题,我们进行了许多尝试,但由于前/后端的物理鸿沟,尝试的方案都大同小异.痛定思痛,今天我们重新思考了"前后端"的定义,引入前端同学都熟悉的NodeJS,试图探索一条全新的前后端分离模式. 随着不同终端(Pad/Mobile/PC)的兴起,对开发人员的要求越来越高,纯浏览器端的响应式已经不能满足用户体验的高要求,我们往往需要针对不同的终端开发定制

dotnet core webapi +vue 搭建前后端完全分离web架构(二)

前言 最近几年前后端分离架构大行其道,而且各种框架也是层出不穷.本文通过dotnetcore +vue 来介绍 前后端分离架构实战. 涉及的技术栈 服务端技术 mysql 本项目使用mysql 作为持久化层 orm dapper 短小精悍,被称为orm中的瑞士军刀.作者之前使用EF 比较多,总感觉 EF 对一些复杂查询需要原生sql支持的不是那么好,EF 生成sql 不好控制,涉及对性能要求比较高的地方,优化起来不够理想.作者在最近的几个项目中接触到dapper,它对原生sql查询支持的相当给力

教你如何前后端完全分离(非api、ajax)

我的前后分离,不是api,不是ajax,我这里只讨论html与后端结合 前话 曾经风靡一时的dedecms相信做网站的十有八.九都知道,还有那么一些不是技术出生的人,通过看一下文档,也能访问出网站出来,有的人说dedecms太垃圾了,不知道是从哪些方面来说的,但不得不承认它的优势,又有哪个框架免费给你用,还这么方便的呢 话说回来,dedecms的一大好处就是会模板标签,差不多就会慢慢的做套网页了,真的就是这么简单 phper技术到底如何 之前我面试过一些人,当然我不会拿网上一些现成的试题,或感觉

Web系统开发构架再思考-前后端的完全分离

前言 前后端完全分离其实一直是Web开发人员的梦想,也一直是我的梦想,遥想当年,无论是直接在代码里面输出HTML,还是在HTML里面嵌入各种代码,都不能让人感到满意.期间的痛苦和纠结,我想所有Web开发人员都深有感触. 由于最近几年一直在MS平台,从Web Form到MVC,MS平台虽然易用好学,但整合度太高而灵活性不足,一直没有找到很好的前后端分离的思路. (Java平台的兄弟如果已经有非常成熟的平台和思路,最好能简单留个言给个帖子地址或者技术名称,不胜感激). ASP.NET的MVC模式的确

一个简单粗暴的前后端分离方案

项目背景 刚刚参加完一个项目,背景:后端是用java,后端服务已经开发的差不多了,现在要通过web的方式对外提供服务,也就是B/S架构.后端专注做业务逻辑,不想在后端做页面渲染的事情,只向前端提供数据接口.于是协商后打算将前后端完全分离,页面上的所有数据都通过ajax向后端取,页面渲染的事情完全由前端来做.另外还有一个紧急的情况,项目要紧急上线,整个web站点的开发时间只有两周,两周啊!于是在这样的背景下,决定开始一次前后端完全分离的尝试. 之前开发都是同步渲染和异步渲染混搭的,有些东西可以有后