① web开发中，怎样做到前后端分离
一般情况下
前端的工作：实现整一个前端页面以及交互逻辑，以及利用ajax与服务器（中间层)交互，使用javascript的模板技术
后端的工作：提供API接口，与数据库交互
② oa系统开发前后端分离前端用什么技术比较好
目前java语言是最稳定的，高端OA如用友泛微等，都是用java开发的，所有的语言见下面 OA软件的开发语言很多，目前较为常见的有ASP/PHP/的技术工程师，从这个市场热度不难看出--JAVA和在扩展、升级、模块化方面的均衡优势。第三:还有一个最为简单的验证方法，就是可以问问你身边搞过研发或者懂点计算机语言技术的朋友，他们都会给你一个明确的答案。 .NET语言开发的软件产品稳定性较高，产品可以模块化是一个存在的事实优势，但.NET具有很强的优势的同时，也存在一定的劣势，如跨平台、大数据并发。同时.Net与ASP对接时，就会导致产品的安全性变低，.NET平台的安全性会随着ASP的安全漏洞安全为黑客或者不法分子利用进而破坏，这个也就一直困扰软件技术工程师的一个最大的问题--.NET语言没有办法和ASP对接的最大一个因素之一。当然.NET如果不需要与ASP语言对接，那么也不存在这样的风险。 目前国内基于.Net 的OA产品有:金和C6(高端版本) 5. JAVA JAVA是1995年由SUN公司引进到我们这个世界的革命性变成语言，今天我们记住SUN这一全球性大公司的原因就是因为SUN在网络安全系统方面是最为优秀的提供商，JAVA的优秀在于与传统的软件比较就是:传统的软件往往与具体的视线环境有关，一旦环境有所变化就需要对软件做一番改动，耗时费力，而JAVA编写的软件能在执行码上兼容，只要服务器提供JAVA解释器，JAVA编写的软件就能在其上运行(更多解释可以见清华大学出版社出版JAVA2实用教程(第二版)，在这免费做做广告o(∩_∩)o…)。 JAVA比.Net相比,可以跨平台，具有非常强的扩展性;可以在LINUX,UNIX上部署。对于超大型的OA系统,这是至关重要的。Windwos平台想实现上千并发不太现实，这是一个绝对的事实。JAVA在扩展性和稳定性上(SUN在网络安全方面的持续支持)的优越表现导致银行、税务、公安、政府这样基于有很高安全要求的公司或者单位在选择软件才产品的时候会首先选择JAVA语言开发的软件产品。 目前国内基于JAVA的OA软件:泛微的Ecology;用友致远;35互联老板签批系统。 由于JAVA和.NET语言开发的产品稳定性和安全性比较高的众所周之的原因，所以在OA软件的应用中使用JAVA和.NET语言开发的OA软件销售的价格会比ASP和PHP开发的软件价格通常要高，但是随着JAVA和.NET的语言技术的大规模使用，一旦JAVA和.NET开发的OA软件进入中低端市场，PHP和ASP结构的OA软件也将会面临全面被取代的局面。 目前国内OA行业中还有一种“功能为王”的声音，这部分主要是依靠ASP、PHP语言技术为主导的商家，这部分商家通常会强调“功能为王”，主观上来看这其实并不错，但是如果站在长期的目标来看，功能为王并不贴切，现有的功能满足并不等于未来的功能满足，JAVA和.Net之所以成为主流，这一点是任何技术流派不能阻止的，越老越多的软件工程师在学习使用这两种计算机语言，他们当然知道选择的原因。OA选型人员应该从更加长远的角度选择OA产品。找到最适合自己的OA软件产品最为重要。
③ 如何评价淘宝 UED 的 Midway Framework 前后端分离
评价淘宝 UED 的 Midway Framework 前后端分离：
1，扩大了前端的势力范围，
对技术影响力、招聘、造轮子、发paper、晋升答辩极为重要。要知道在阿里前端最高的级别是P8，人数则一只手能数的过来。这不能不说是前端这一层过于薄、离业务核心太远导致的，现在从技术上侵入服务端，技能树终于开了新分支，可能性猛然大了无数倍，一下子似乎发现了新大陆。对个人成长的渴望，是大量面临瓶颈的资深前端工程师无法抗拒的诱惑！
2，前端开发模式的变革。
自己玩后端，技术上、项目上都不用去看后端项目的排期和配合了，极大提高了开发和测试的便利度、自主性。阿里很早就了nodejs写的开发服务器用于内部测试，现在走到线上，也是厚积薄发，这为提高开发效率，进一步榨取前端劳力提供了可能。
3，促进阿里后端web框架的进化。
这一点是没有很多人甚至阿里人没注意到的（前端不懂webx，后端重心后移），webx框架发布已经很久，近期的技术升级非常少，技术形态已经陷入僵化，对现在的移动互联网趋势没有敏锐的发现机会并适应变革，很遗憾地缺席了新时代。nodejs来了，洗牌开始，前端人员天然对多终端、多屏、交互、体验的关注会为后端框架吹过一缕新风，给这停滞的技术领域注入活力。——所以我是赞成后端工程师学习nodejs的。
同时问题也很多，这些困难和隐患不能不提：
1，不可忽视的后端技术门槛。
不能不提这茬，即便midway很务实的只挑选了视图层作为主攻方向，但不可避免的控制器层还会带进来大量技术问题需要解决，比如配管、部署、日志监控、运维工具、SOA、加解密、事务、缓存策略、消息队列、异步调用、安全问题，总有避不开的暗礁。对阿里目前的后端技术栈来说，这些技术背后是无数的系统和平台，缺一不可，midway目前还是个玩具。更何况nodejs/web framework本身都在飞速演变之中，ES5到ES6，技术特性变化剧烈。即便由前期探路者完成了基础设施建设，后期他人进入的学习成本也非常高。时间长了，前端工程师本身又自然会分化成纯前端和nodejs工程师，如此前后端天然又产生了隔阂，呵呵，分久必合，合久必分。
2，前端不务正业。
正是因为困难重重，后端技术比前端复杂，加上新领域容易出成果，客观上造成了前端精英力量会大量倾斜到这个领域，进而使纯前端技术停滞不前，内部人心浮动，如果管理上不能很好理清长期目标和短期计划、前后端如何分离等关系和利益的要害问题，对公司来说是喜忧参半的。
3，JS的技术缺陷
因为ES一直在进化中，ES6的yield部分解决了callback hell，mole也初步有了，但是楼上推崇的前后端代码共享和模板共享，在我看来恰恰不太可行。对阿里来说，后端代码是需要保护的，大量模板、校验函数等代码如果暴露出去，对网站的安全是一大威胁，这个好处实在鸡肋。譬如最近我们就发现JDK的一个加密类库在js中根本找不到替代方案，自己写的话实在力有不逮。nodejs还太幼小，还有很多技术问题就不展开了。
4，好处不够明显，推广困难。
这才是midway真正的死穴。如前文所说，目前的前后端分离运动还是部分前端工程师的孤立行为，绝大多数后端工程师和一线主管对此毫不关心（我除外），因为midway宣称的痛点不是他们的痛点，宣称的优点只有节约后端人力这一条对他们有点意义，而这些人才是决定midway命运的人！随着时间的推移，这可能缓解，也可能尖锐，毕竟这是前端们的西部大开发运动，是扩地之战。
总结。
目前midway至少还有半年的路要走，前端要克制自己的冲动，有限度使用nodejs，相信在这个领域大有可为，但那时候他们就不是前端了，他们会有一个响亮的名字叫 “NodeJS工程师”。
④ javaweb前后端分离前端用什么技术
前后端分离，后端只要返回前端json格式数据就可以。至于业务逻辑部分springmvc之类都可以。
⑤ 一个web项目前后端分离，前端工程师需要掌握哪些
首先你要知道什么是web前端工程师：
Web前端开发工程师，其工作岗位主要职责是利用(X)HTML/CSS/JavaScript/DOM等各种Web技术进行产品的界面开发。制作标准优化的代码，并增加交互动态功能，同时结合后台开发技术模拟整体效果，进行丰富互联网的Web开发，致力于通过技术改善用户体验，使得web界面可以更加友好的与用户交互。
Web前端工程师需要的技能：
为网站上提供的产品和服务实现一流的Web界面，优化代码并保持良好兼容性
Web前端表现层及与前后端交互的架构设计和开发
JavaScript程序模块开发，通用类库、框架编写
利用各种Web技术模拟开发产品原型
配合后台开发人员实现产品界面和功能
Web新技术调研和资讯整理
精通HTML/XHTML、CSS，熟悉页面架构和布局，精通Ajax、JavaScript、DOM等前端技术，掌握面向对象编程思想
⑥ 西安北大青鸟分享前后端分离的特点
我们在开发软件和app应用的时候一般都会采用不同的分离模式，下面我们就一起来了解一下，前后端是否分离都有哪些影响与作用。
前后端不分离在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。
这种应用模式比较适合纯网页应用，但是当后端对接App时，App可能并不需要后端返回一个HTML网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端App应用，为了对接App后端还需再开发一套接口。
前后端分离在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。
至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。
在前后端分离的应用模式中，西安电脑培训http://www.kmbdqn.cn/发现前端与后端的耦合度相对较低。
在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。
⑦ 武汉北大青鸟分享前后端分离的特点
我们在开发软件和app应用的时候一般都会采用不同的分离模式，下面我们就一起来了解一下，前后端是否分离都有哪些影响与作用。
前后端不分离在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。
这种应用模式比较适合纯网页应用，但是当后端对接App时，App可能并不需要后端返回一个HTML网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端App应用，为了对接App后端还需再开发一套接口。
前后端分离在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。
至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。
在前后端分离的应用模式中，武汉电脑培训http://www.kmbdqn.cn/发现前端与后端的耦合度相对较低。
在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。
⑧ 前后端系统有没有算法
有的。
算法通过前端登录验证及后端角色权限验证双侧控制用户访问权限，实现访问系统权限控制。随着信息技术的发展以及人们对程序设计要求的提高，逐渐形成一种新型的开发模式，即前后端分离模式基于前后端分离软件系统。
随着信息技术的发展以及人们对程序设计要求的提高，逐渐形成一种新型的开发模式，即前后端分离模式。
⑨ 现在开发网站一般都使用什么方式什么是前后端分离
对于前后端分离，认识上有个误区，那就是很多人自称：我们老早就分离了，全AJAX，使用Angular或者什么什么就可以了。
这个说法是不合适的，打个比方，别人问的是“如何解决家禽把蛋生在水草边的问题？”，但实际上人家养的是鸭子，答题的却是养鸡的，所以回答“不让去水边就行了”，这显然不在点子上。
这
两年业界说的前后端分离，是限于偏展示类的系统（用A代替），而不是应用、管控类Web项目（用B代替），在B类项目里，前后端是天然分离的，对此，除了
少部分后端开发人员，基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目，在B类项目里，前后端分离是共识，不需要讨论。
那么，剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢，在于模板的与数据结合的位置，以及，模板的控制权在谁手里。经过这两年的讨论，基本上我们可以达成的共识就是：模板应当由前端人员去控制，主要原因有两方面：
- 性能优化（尤其是外部资源的管理与发布，请求合并等等）
- 协作的顺畅性（已形成模板的界面片段的返工等问题）
那么，模板到底应该在什么地方跟数据结合？
这个问题就比较折腾了，有部分人尝试像B类项目那样，使用js模板，然后在浏览器端执行，这是存在一些问题的，比如说seo不友好，首屏性能不够，尤其对于首页DOM量很大的电商类网站，差距很明显。
所
以我们还是得把主要的模板放在服务端来执行。在这个过程中，阿里作了一些尝试，那就是引入Node层，在这一层把模板与数据进行合成，然后浏览器拿到的就
是生成好的HTML了，但也不是所有HTML都是这么生成好的，还是会有一些内容等到了浏览器之后，再用js去加载和生成。
所以这一定会是一个混合方案，同一个系统中存在两种模板，一种在服务端执行，一种在浏览器中执行，互为补充。
至
于说这个方案中，是否中间层一定要是node，我觉得无所谓，只要是能正常做web项目的东西都可以，这个还是要看所在企业的技术积累方向，当然node
做这块是有一些优势的，比如对前端人员的语言友好性，前后端模板的通用性等等，但这些都是细节，重点还是整体方案和流程。
这时候回头看你问题中的这句：
> 前后端分离的意思是，前后端只通过 JSON 来交流，组件化、工程化不需要依赖后端去实现。
我相信你这里对前后端的限定是以浏览器为准的，但事实上，A类项目中，前后端的分界一定要延伸到服务器端的模板层，也就是在这一层里，把各种来源的数据整合到模板中，这个数据未必是JSON格式的，会存在有JSON，XML，特定的二进制等等。
组
件化这个话题就更复杂了，在刚才组织形式中，很难说出究竟什么才是组件。是某个商品的模板吗？是数据吗？是数据和模板的结合体吗？没法回答。在此，我说一
句自己的看法：像电商这种项目的前端部分，基本不存在组件的概念，甚至不存在组件化的价值，因为这里面可复用的东西太少了，也不易提取，大多数东西都是不
带逻辑的界面模板。
最近因为ReactJS的流行，带来了一个Isomorphic的概念，这是一种很有意义的探索，但是否能解决这类问
题，尚不得而知，根据我的理解，它对B类项目是较好的补充方案，但对A类项目暂时还缺乏可用性，因为A类项目中，运行期的DOM变更并不多，多是整片的改
变，用这个方案去解决的话，有些牛刀杀鸡的感觉。
关于B类项目的组件化，我之前那个没写完的系列是关于它的，但经过最近一年多的思考，我又觉得需要再重新写一篇东西了。感谢你的问题提醒了我，这就写。