前后端分离与不分离及MVC设计模式简述

前后端不分离

  前端页面的效果都是由后端控制,由后端渲染页面或重定向,也就是后端需要控制前端的展示。

前后端分离

  是一种架构模式,核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。

  如何实现前后端分离呢?前后端工程师需要约定交互接口,实现并行开发,开发结束后需要进行独立部署,前端通过ajax来调用http请求调用后端的restful api。前端只需要关注页面的样式与动态数据的解析&渲染,而后端专注于具体业务逻辑。

MVC设计模式

  Model—View-Controller 模型-视图-控制器

  Model数据层:数据库数据的增删改查

  View视图层:做html页面的展示

  Controller逻辑层:书写业务逻辑

  如何工作呢?举个例子:你在页面输入一个网址(请求-Request),这个网址去调用接口,这个接口其实就是访问后端的一段代码(方法),后端有很多方法,如何确定访问的是哪个方法?就是接口定义好的,比如:177.0.0.1/api/user/login,这里面的api就表示一个服务(一个工程),user表示一个类,login表示具体要调用的那个方法,你一旦回车,就直接调用了后端这个方法,后端这个方法就去数据库(MySQL|Oracle|其他)取数据,数据库表中每一行数据就表示一个对象,最后存到集合框架(List|Map|Set|等)中,方法把这个集合返回,那么调用这个接口的结果就是会响应(Response)给你一个结果集,前端就拿到了这个数据,然后通过页面(html|Jsp)展现出来,最后用户看到的就是View层做的事情。

原文地址:https://www.cnblogs.com/snowstorm22/p/10257321.html

时间: 01-11

前后端分离与不分离及MVC设计模式简述的相关文章

[转]从MVC到前后端分离

从MVC到前后端分离 来源:csdn 发布时间:2015-10-26 阅读次数:1680 1. 理解MVC MVC是一种经典的设计模式,全名为Model-View-Controller,即模型-视图-控制器. 其中,模型是用于封装数据的载体,例如,在Java中一般通过一个简单的POJO(Plain Ordinary Java Object)来表示,其本质是一个普通的Java Bean,包含一系列的成员变量及其getter/setter方法.对于视图而言,它更加偏重于展现,也就是说,视图决定了界面

从 MVC 到前后端分离——转自:OSChina 黄勇

转自:OSChina 黄勇 从 MVC 到前后端分离 1 理解 MVC MVC 是一种经典的设计模式,全名为 Model-View-Controller,即 模型-视图-控制器. 其中,模型 是用于封装数据的载体,例如,在 Java 中一般通过一个简单的 POJO(Plain Ordinary Java Object)来表示,其本质是一个普通的 Java Bean,包含一系列的成员变量及其 getter/setter 方法.对于 视图 而言,它更加偏重于展现,也就是说,视图决定了界面到底长什么样

关于大型网站技术演进的思考(十七)--网站静态化处理—满足静态化的前后端分离(9)

前后端分离的主题虽然讲完了,但是前后端分离的内容并没有结束,本篇将继续前后端分离的问题,只不过这次前后端分离的讲述将会围绕着本系列的主题网站静态化进行.在讲本篇主题之前,我需要纠正一下前后端分离主题讲述中会让朋友们产生误导的地方,这种误导就是对时下流行的一些前后端分离方案(没有使用nodejs的前后端分离方案)的评价问题,其实本人任然觉得不管什么样的前后端分离方案只要成功被实施,并且产生了良好的效果,那么它就是一个成功的前后端分离方案,前面我以一种批判的角度讲述这些前后端分离方案,并不是想在否定

重写IHttpHandler,实现前后端分离

再说重写IHttpHandler,实现前后端分离 aspx页面第一次加载时,HttpHandler 里面是如何编译指定页面的呢?Framework提供了编译页面的API如下: BuildManager.CreateInstanceFromVirtualPath(url, typeof(System.Web.UI.Page));根据虚拟路径生成实例. 但是url页面此时必需继承System.Web.UI.Page,就是我们常见的ASPX页面.但是这样编译时会调用aspx视图引擎来解析aspx和对应

关于大型网站技术演进的思考(十五)--网站静态化处理—前后端分离—中(7)

上篇里我讲到了一种前后端分离方案,这套方案放到服务端开发人员面前比放在web前端开发人员面前或许得到的掌声会更多,我想很多资深前端工程师看到这样的技术方案可能会有种说不出来的矛盾心情,当我的工作逐渐走向越来越专业化的前端开发后,我就时常被这套前后端分离方案所困惑,最近我终于明白了这个困惑的本源在哪里了,那就是这套前后端分离方案其实是服务端驱动的前后端分离方案,它的实现手段又是从服务端的MVC架构体系演化而来,因此该方案最大的问题就是它并没有从根本上改变web前端从属于服务端的被动局面.那么问题来

关于大型网站技术演进的思考(十四)--网站静态化处理—前后端分离—上(6)

前文讲到了CSI技术,这就说明网站静态化技术的讲述已经推进到了浏览器端了即真正到了web前端的范畴了,而时下web前端技术的前沿之一就是前后端分离技术了,那么在这里网站静态化技术和前后端分离技术产生了交集,所以今天我将讨论下前后端分离技术,前后端分离技术讨论完后,下一篇文章我将会以网站静态化技术的角度回过头来重新审视下前后端分离技术,希望通过这种审视来加深我们对两套技术的理解. 前后端分离技术我个人认为是web前端被专业化以后的必由之路,而nodejs的出现是前后端分离技术的一个强兴的催化剂,原

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

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

架构设计:前后端分离之Web前端架构设计

在前面的文章里我谈到了前后端分离的一些看法,这个看法是从宏观的角度来思考的,没有具体的落地实现,今天我将延续上篇文章的主题,从纯前端的架构设计角度谈谈前后端分离的一种具体实现方案,该方案和我原来设想有了很大的变化,但是核心思想没变,就是控制层是属于Web前端的. 在以前文章里我说道前后端分离的核心在于把mvc的控制层归为前端的一部分,原方案的构想在实际的生产开发里很难做到,我觉得核心还是控制层和视图层的技术异构性,这样后果使得系统改造牵涉面太大,导致在项目团队里,沟通.协调以及管理成本相对较高,

关于Web前后端分离的体验

由于公司有一个特殊的项目,以前是完全用php(smarty)写的一个程序,现在要转向php+node.因此一不小心又给后端同学们灌输了下用node做前后端分离的思想. 以前在知乎上答过这样的问题.大概如下 http://www.zhihu.com/question/26835139 由于目前正在做angular的项目,因此体验更加深刻. 现在再来说一下前后端分离的想法吧,还是有点借鉴http://ued.taobao.org/blog/2014/04/full-stack-development

前后端分离之后添加验证码

转载自:http://www.cnblogs.com/liminjun88/p/6556493.html#commentform 1.背景介绍 团队开发的项目,前端基于Bootstrap+AngularJS,后端Spring MVC以RESTful接口给前端调用.开发和部署都是前后端分离.项目简单部署图如下,因为后台同时采用微服务的方式,所以后台不止3个,画图示意.终极方案是采用Docker,在前端和后台调用中间添加一层:API Gateway. 因为考虑到和其他系统集成的可能性,所以在登录这一