‘壹’ 有哪些主流的web框架
1、Spring
Spring是于2003 年兴起的一个轻量级的Java开发框架，是一个开放源代码的设计层面框架，他解决的是业务逻辑层和其他各层的松耦合问题，因此它将面向接口的编程思想贯穿整个系统应用。简单来说，Spring是一个分层的JavaSE/EE full-stack(一站式) 轻量级开源框架。
2、SpringBoot
Spring Boot是由Pivotal团队提供的框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。
3、Thymeleaf
Thymeleaf是面向Web和独立环境的现代服务器端Java模板引擎，能够处理HTML，XML，JavaScript，CSS甚至纯文本。
4、Druid
Druid是阿里的一个开源高效的数据查询系统，主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。
5、mybatis
MyBatis 是一款优秀的持久层框架，它支持定制化 SQL、存储过程以及高级映射。MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息，将接口和 Java 的 POJOs(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录。
6、Hybernate
Hibernate是一个开放源代码的对象关系映射框架(Object_Relative DateBase-Mapping 简称ORM)，它对JDBC进行了轻量级的对象封装，它将POJO与数据库表建立映射关系。 Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序使用，也可以在Servlet/JSP的Web应用中使用。
‘贰’ RESTFUL webservice + MVVM框架实现的web应用安全性怎么样
最近挺流行RESTFUL webservice + MVVM框架去实现web应用，好像.net 常用的的web api + knockout js， java常用spring mvc restful + angular（或其他）。
但是感觉使用mvvm框架会把页面操作的代码暴露了出来，别人知道了页面操作的js文件，就会看到那些修改、删除、添加的url，然后使用fiddler等工具，就可以跳过你的应用去修改数据了。
‘叁’ 你对MVC、MVP、MVVM 三种组合模式分别有什么样的理解
各大软件和系统，包括现在的手机，都趋向于mvp，web更倾向mvc但是也有趋向于mvp的。感觉核心就是从mv+一个代理方式，只要这个方式方便测试，降低耦合就会不断改进
‘肆’ Web前端真的需要用MVVM框架吗
这个完全看业务方向和公司需求， 我做前端4年了，也是从BAT出来，但是没有过那么强烈的需求做 mv* 神马的。 掌握好WEB开发基本原理和基础前端技术，夯实编程功底显得更加重要，你完全可以轻松的根据自己所在公司的业务特点开发一套更加贴合自己的 MVVM 框架。
开课吧有一些实战案例的视频教程，个人感觉内容还不错，推荐你去试听一下，希望你能够在web开发的道路上越走越远！
‘伍’ Web前端开发：为何选择MVVM而非MVC
在Web中充斥着所谓的MVC框架，而在我看来，因为一些关键性的技术原因，MVC在Web前端开发中根本无法使用(对的，是无法，而不是不该) 。在MVC原始报告中指出：view永远不会知道用户输入，比如鼠标操作和按键。很显然，在Web前端，你无法做到这一点，因为Web的程序中，用户的输入必须通过监听窗口、文档和元素上的事件来获得。——而这些东西常常被认为是View。于是一些奇怪的认识诞生了，比如认为Controller应该是View操作Model的中介。我曾经尝试设计一个编程模型让所有的事件流经Controller，但是事实上我发现这样的做法非常糟糕。——这个尝试让我从MVC转向了MVVM。John Gossman（WPF的架构师）在他的文章中提到，Model/View/ViewModel中的View表示可见元素，按钮，窗体，图形或者GUI中更复杂的控件，它会对快捷键进行编码，并且控件自身会管理跟输入设备的交互——这在MVC中本该是Controller负责的（现代GUI环境中发生在Controller上的事情是很长的题外话……我倾向于认为它只是隐藏到后台了，它仍然存在，但是我们不需要像是1979年那样考虑那么多事情了）MVC这样的结构的正确性在于，任何界面都需要面对一个用户，而Controller “是用户和系统之间的链接”。在经典MVC中，Controller要做的事情多数是派发用户输入给不同的View，并且在必要的时候从View中获取Editor来更改Model，而Web以及绝大多数现在的UI系统中，Controller的职责已经被系统实现了。下面的图片说明了这样的演进过程：总而言之，对于MVC为1979年的SmallTalk设计
界面和程序都由同一种语言编写用户输入完全由程序编写者来处理View是单纯用于显示对于MVVM为2005年的WPF设计
界面多使用标记语言，程序则使用编程语言用户输入经过UI系统底层处理和分发，多数以事件的形式被用户程序所知View具有独立性，能够管理部分用户输入并且自行反应（它们常常被称作控件，而非视图）作为一个Web开发者，在二者之间做出何种选择是显而易见的。
‘陆’ 网站开发框架和web前端框架的区别,
你说的网站开发框架应该是后端开发框架，后端开发语言有多种多样，一般多是mvc架构，而web前端框架一般是mvvm架构，所以还是有区别的。
主要区别在于后端有c层，即控制器，主要用于程序控制。而前端没有控制器，只是实现双向绑定。
‘柒’ mvp，mvc和mvvm的区别
MVC,
MVP和MVVM都是用来解决界面呈现和逻辑代码分离而出现的模式。以前只是对它们有部分的了解，没有深入的研究过，对于一些里面的概念和区别也是一知半解。现在一边查资料，并结合自己的理解，来谈一下对于这三种模式思想的理解，以及它们的区别。欢迎各位高手拍砖。
阅读目录:
复制代码
代码如下:
一. MVC, MVP, MVVM诞生的需求?
二. 一段典型的耦合代码
三. MVC模式
3.1 主动MVC
3.2 被动MVC
3.3 Web应用中的MVC框架
3.4 MVC总结
一，MVC, MVP, MVVM诞生的需求?
软件中最核心的，最基本的东西是什么?
是的，是数据。我们写的所有代码，都是围绕数据的。
围绕着数据的产生、修改等变化，出现了业务逻辑。
围绕着数据的显示，出现了不同的界面技术。
没有很好设计的代码，常常就会出现数据层(持久层)和业务逻辑层还有界面代码耦合的情况。
ORM等框架，解耦合了业务逻辑和数据之间的耦合，业务逻辑不再关心底层数据如何存储和读取。所有数据呈现给业务逻辑层的就是一个个的对象。
而MVC,
MVP, MMVM用来解决业务逻辑和视图之间的耦合。
二，一段典型的耦合代码
复制代码
代码如下:
{
SqlDataAdapter adapter = new SqlDataAdapter("select * from
Table1","server=.;database=db;uid=sa;pwd=password");
DataSet ds = new DataSet("ds1");
adapter.Fill(ds);
this.GridView1.DataSource = ds;
this.GridView1.DataBind();
}
上面的这段代码中，既包含了数据访问，还包含的页面展示。当项目复杂程度更高，这种代码就会变得非常难以维护，层次也不清晰。
三，MVC模式
MVC全名是Model View
Controller，是模型(model)－视图(view)－控制器(controller)的缩写。MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式
3.1 主动MVC
MVC的理论思想对应的是主动MVC, 这里的主动的意思是, Model会主动通知View更新。而我们使用MVC框架,
Struts, asp.net mvc等都不是主动MVC(视图的更新都是通过Controller完成的)
Model
用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。
模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。
View
视图层负责数据的展示。
在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里订阅Model的事件。
Controller
控制器是M和V之间的连接器，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据模型上的改变。
3.2 被动MVC
下图是被动MVC中的流程，和主动MVC不同之处是,
View没有订阅Model数据变化的事件，等待Model来通知需要根据新的数据来更新View. 在被动MVC中，Controller负责通知View,
有数据变化，需要更新视图。
被动MVC 中，与主动MVC的区别在于：
1、模型对视图和控制器一无所知，它仅仅是被它们使用
2、控制器使用视图，并通知它更新数据显示
3、视图仅仅是在控制器通知它去模型取数据的时候它才这么做(视图并不会订阅或监视模型的更新)
3.3. Web应用中的MVC框架
Web中的MVC框架都是被动MVC模式，因为web应用中,
由于http是基于请求和响应方式协同工作的,因此当服务器端的model(数据)发生变化时,它不会立即更新客户端的view,只有客户端重新请求或刷新页面时才更新.
下图是典型的MVC框架中的MVC一个请求流程。
3.4 MVC总结
MVC优点
•由于MVC很好的分离了视图层和业务层，所以它具有以下优点
•耦合性低
•开发速度快
•可维护性高
•没有控件的概念，对html没有封装，易于理解
•和其它平台(java, php)等更加相似。便于人才获取
MVC使用的误区
1.把Model理解成实体类（Entity），在MVC中Model应该包含2部分功能，一部分是处理业务逻辑，一部分是提供View显示的数据
2.把业务逻辑全部放在Controller端
这两个误区本质上都是对Model的作用不明导致的。
Model在MVC架构中起的作用非常重要，它应该是业务逻辑真正的实现层。所以Model的实际上是Business
Model（业务模型）。而Controller仅仅起一个“桥梁”作用，它负责把View的请求转发给Model，再负责把Model处理结束的消息通知View。Controller是用来解耦View和Model的，具体一点说，就是为了让UI与逻辑分离（界面与代码分离）。
引自http://www.techopedia.com/definition/27454/model-mvc-aspnet
复制代码
代码如下:
Techopedia explains Model (MVC)
The
Model is the part of MVC which implements the domain logic. In simple terms,
this logic is used to handle the data passed between the database and the user
interface (UI).
The Model is known as domain object or domain entity.
The domain objects
are stored under the Models folder in ASP.NET. The domain model represents the
application perspective for the data to be handled whereas a view model is
required to proce the engine that generates the View.
This definition was written in the context of ASP.NET.
MVC的缺点
完美的MVC应用场景应该是这样的:
有个Student Model, 关联StudentListView, StudentEditView.
对于StudentListView,
Student Model提供Student的集合数据来显示StudentListView
对于StudentEditView, Student
Model提供单个Student数据来展示StudentEditView并且响应StudentEditView的保存操作。
但是这只是完美的情况，实际应用中，在ListView上，不单单显示Student的信息，可能还需要这个Student的历史成绩，家庭情况,
老师信息。而这些是Student Model不能提供的。
也许我们可以扩展Student Model, 将Student
Model能够提供的信息扩展，包含成绩信息等，这本身也可以。但是，如果Student显示的View，这个需要只是需要额外的成绩信息，另一个View只是需要额外的家庭信息，Student
Model是不是有些疲于奔命，你能知道还会有多少个差异化的View的需求? 而且让逻辑端代码这样不断的修改来适应View端，好吗?
由于MVC的设计思想是从Model出发，而没有考虑到View端的复杂性，这样导致的问题是Model难以符合复杂多变的View端变化。
相对这点，MVP和MVVM就要好得多。它们都独立出了Presenter
和ViewModel来对应每个View。
‘捌’ 什么是MVVM
但其无法与我们的用户进行交互, 所以, 我们需要为其创建一个界面(视图, View), 该视图可以与用户输入设备进行交互, 这很棒, 但问题是如何将View与我们的model关联起来? Binding便可以发挥作用了, 比如视图上的某一个文本框中的文本和Model中的"用户名"关联起来, 用户便可以通过操作该文本框来访问和修改Model的"用户名"了。这是极其简单的情况, 但实际编程时我们发现, Model中的属性(与方法)往往不那么容易与View中的界面控件关联起来, 比如, "类型不匹配": 界面控件所需要的类型与模型中属性提高的类型不匹配. "需要额外操作": 模型中的数据需要经过一些额外的处理才能传给视图,反之亦然. 此时, 我们意识到View似乎需要一个"Helper"类来处理一些额外工作.
这个helper所包含的代码可以放在除了Model外的很多地方(我们现在不考虑贫血富血之类的争论), 比如View中, 记得自己刚学习窗体程序开发时就是这么干的, 将绝大多数处理逻辑放在那个所谓的CodeBehind中. 后来,正如大家在各种设计模式书籍中所看到的一样,为了将View和Model剥离开来,实现view可替换(比如你可以讲自己精心设计的软件同时运行于窗体程序,Web甚至Mobile上), 便有了MVC. 有了MVC以后似乎就开始滋生M-V-XXX之类的争论与变种模型, 比如MVP以及这里的MVVM,甚至MVP也有着Supervising Controller与Presentation Model两种方式. 但主要围绕两个问题,一是model与view之间的关系, 完全隔离的?单向的还是双向的? 二是这个"XXX"需要完成哪些功能,简单流程调度?复杂规则处理? OK,这些争论都没有关系, 是否采用某种模式取决于你的开发所处的环境(比如语言特性,框架特性)以及你的业务特性以及所面临的主要变化点等等。但与MVC,MVP所不同的是,MVVM的引入不仅仅是技术上的原因(解除耦合应对变化等老生常谈),另外一个很大原因是:软件团队开发方式的改变.如果你做过一段时间的WPF项目开发的话,你可能会有比较明显的感觉:在View层打造上,如何分配程序员和美工的工作.在继续阅读之前,大家可以看看我以前的一篇文章"在UI Designer与Developer之间". 以前我们团队采用的便是"集成模式", 我便兼职了其中的"Integrator"角色.这还不错.但说实在的,这仅仅是一个在特殊情况下不得已而为之的暂时方案,所以我们付出了很大的努力开始转向"收割模式"了,要转向这个模式,至少需要两个基本条件:(1)你拥有能够熟练运用Blend等工具能为程序员输出XAML的美工, 他专注于纯粹的UI/UE, 另外他还必须具有一定的"程序员"思维.以便输出的东西能很好地作为程序的一部分而运转起来,而不是仅仅"看上去"是那样的。(2)你需要能够脱离View层但仍能编写出高质量代码的程序员。幸运的是, 我们在努力创造条件1,并取得了很好的效果.(你可以招一个具有Flash脚本编写经验的并且有极大的学习热情的美工人员, 并对他进行Blend的相关培训). 而MVVM模式为我们实现第二个条件提供了极大的便利. 为什么MVC/MVP模式不行而MVVM可以呢? 很简单, 在MVC和MVP模式中, View层都具有很多代码逻辑, 开发View层的是程序员, 虽然UI/UE团队会做很多工作, 但这个层的"实现者"仍然是程序员. 在以前的开发中,其工作得很好, 而在WPF开发中程序员对View层的展现显得力不从心了,美工(指符合上面条件1的美工)虽然很擅长, 但他会说"可惜我不会程序".于是, 我们需要一种方式将View层的代码逻辑抽取出来,并View层很纯粹以便完全让美工去打造它.相应地, 需要将View层的相应逻辑抽取到一个代码层上,以便让程序员专注在这里。回想一下, 我们只所以要在View(Xaml)背后写一些代码(C#), 无非是想传递一些数据以及传递数据时的数据的处理或在用户与界面控件进行交互时执行一些操作, 最简单的例子是在MVC中当界面发生交互时View去调用Controler中的某个方法, 以便将该操作的相应"指示"传递到"后台"去. 在以前的技术中, 这样的"衔接性"的代码是必须的. 而在WPF中, 则可以通过另外的技术来进行层与层之间的"衔接", 这就是"Binding" 和"Command", 以及稍后我们会提到的"AttachBehavior". 通过Binding, 我们可以实现数据的传递; 通过Command, 我们可以实现操作的调用.(AttachBehavior的作用稍后再谈). Binding和Command是可以写在XAML中的, 这样看来XAML后面对于的CS文件可以被完全抛弃或不予理会了. 这样的XAML文件正是美工所需要的. 而这些对于Binding以及Command的定义描述以及其他相关信息的代码应该放在那里呢, 当然不是View, 更不是Model, 是"ViewModel". ViewModel是为这个View所量身定制的, 它包含了Binding是所需的相关信息,比如Converter以及为View的Binding提供DataContext, 它包含了Command的定义以便View层可以直接使用, 另外,它还是一个变种的Controler, 它得负责业务流程的调度。于是, 便有了这副图, 然后, 正如"时势造英雄"所言, MVVM就诞生了.3、ViewModel 与单元测试如果你是一名正在使用MVVM模式打造软件的程序员, 那么我劝你尽快忘掉View. 你所面对的是这样一个模式"UnitTest-ViewModel-Model"(这并非一个模式, 仅仅是我为阐述观点而暂时如此表述的)。记得曾经有一个Model-View-AbstractView模式, 而MVVM中的VM实际也是一个AbstractView: the abstraction of view. 它是一个抽象的View, 具有一个View的灵魂,而不具备相应的可视化控件而已. 所以对于程序员而已, 打造这样一个抽象的VM就可以认为是完成View层的打造了.而当美工完成无数控件组成的实际的View后, 我们就可以用Binding和Command这样的黏合剂将这个抽象的View和实际的View黏合在一起了。那么在黏合之前, 我们怎么知道自己的VM是否正常工作呢? 单元测试!在说明对于ViewModel进行单元测试的重要性之前, 送给大家一句话: "View and Unit Test are just two different types of ViewModel consumers" (Josh Smith). 如果我们将ViewModel看作生产者, 那么View和Unit Test都是具有同等地位的消费者而已. 并且UnitTest相比于View而言具备更大的消费能力. 或者你可以简单的认为View也仅仅是一种不太推荐的测试方式而已. 所以要实施好这个模式, 那么对ViewModel的单元测试就是必须的了,并且这个测试要不依赖于任何UI控件. (那么不是不对应ViewModel的开发是不是就应该通过测试来驱动了?TDD?
‘玖’ Web 前端开发需要使用 MVVM 框架吗
不一定，mvvm就是像angular.js和value.js这种框架所用的数据双向绑定模式，所以开发要根据实际需求来进行定位，框架只是提供了实现的快速方式
‘拾’ vue，angular，avalon这三种MVVM框架之间有什么优缺点
Vue.js
老师写的一个用于创建 web 交互界面的库，是一个精简的 MVVM。从技术角度讲，Vue.js 专注于 MVVM 模型的 ViewModel 层。它通过双向数据绑定把 View 层和 Model 层连接了起来。实际的 DOM 封装和输出格式都被抽象为了Directives 和 Filters。Vue.js和其他库相比是一个小而美的库，作者的主要目的是通过一个尽量简单的 API 产生可反映的数据绑定和可组合的视图组件，感觉作者的思路非常清晰。
优点：
简单：官方文档很清晰，比 Angular 简单易学。
快速：异步批处理方式更新 DOM。
组合：用解耦的、可复用的组件组合你的应用程序。
紧凑：~18kb min+gzip，且无依赖。
强大：表达式 & 无需声明依赖的可推导属性 (computed properties)。
对模块友好：可以通过 NPM、Bower 或 Duo 安装，不强迫你所有的代码都遵循 Angular 的各种规定，使用场景更加灵活。
缺点：
新生儿：Vue.js是一个新的项目，2014年3月20日发布的0.10.0 Release Candidate版本，目前github上面最新的是0.11.4版本，没有angular那么成熟。
影响度不是很大：google了一下，有关于Vue.js多样性或者说丰富性少于其他一些有名的库。
不支持IE8：哈哈不过AngularJS 1.3也抛弃了对IE8的支持，但是
老师的avalon是支持IE6+的，应该下了很多努力去优化。这一点对于那些需要支持IE8的项目就不好了，不过这也是web前端开发的一个趋势，像IE低版本就应该退出历史舞台了，通过改变我们的前端思维，而不是顺应那些使用老版本而不去升级的人。
老师就说过一句话，我觉得说的非常好“这年头，支持 IE6、7 早就不再是特性，而是耻辱。努力推动支付宝全面不支持 IE6、7，期待更多兄弟加盟”。
AngularJS
AngularJS最近很火，追随者也很多。 Superheroic JavaScript MVW Framework
官方说得很朴素：“完全使用JavaScript编写的客户端技术。同其他历史悠久的Web技术（HTML、CSS和JavaScript）配合使用，使Web应用开发比以往更简单、更快捷“。当你学习它的时候，我相信你会被它的很多新特效所吸引。
优点：
动态视图：以前从来没有想过js可以如此扩展HTML的属性，但是AngularJs做到了，它替我们静态的HTML加了很多扩展性功能，有一种让HTML由死变活的感觉。
完善：是一个比较完善的前端MVW框架，包含模板，数据双向绑定，路由，模块化，服务，依赖注入等所有功能，模板功能强大丰富，并且是声明式的，自带了丰富的 Angular 指令。
Google维护：AngularJS有Google来维护，无疑有了一个强大的后台，对于推广和维护明显比Vue.js和avalon有优势，社区也非常活泼，能够很好促进它的发展。
AngularJS & Ionic：Ionic: Advanced HTML5 Hybrid Mobile App Framework，这俩就是一个好基友，Ionic通过用AngularJS为了创建一个框架，最适合开发的丰富和强大的应用程序。上次于知乎答了一个相关问题做webapp开发，性能和效率最好的框架和打包app平台分别是哪个？ - 汤威的回答，详细可以见这里。
缺点：
大而全：学习起来有难度，对于我来讲学习曲线很曲折，比较难理解一些。
推翻重写：前段时候逛社区发现AngularJS2.0会把之前的推翻重写，两个框架的改变很大，基本是两个框架了，等于是说等到2.0出来后又需要从头开始，不过又说回来，
老师的［翻译］有关Angular 2.0的一切 · Issue #8 · xufei/blog · GitHub这篇文章很好说明了AngularJS2.0的变化。
不支持IE8以下，貌似2.0变得只支持移动端了，等到出来后再看吧。
Avalon.js是
老师所写的个简单易用迷你的MVVM框架，它最早发布于2012.09.15，为解决同一业务逻辑存在各种视图呈现而开发出来的。常常可以看到老师推广他的Avalon.js，出了很多教程，无疑对国内学习Avalon.js的人提供了巨大方便。
优点
使用简单，在HTML中添加绑定，在JS中用avalon.define定义ViewModel，再调用avalon.scan方法，它就能动了！
兼容到 IE6 (其他MVVM框架，KnockoutJS(IE6), AngularJS(IE9), EmberJS(IE8), WinJS(IE9) )，另有avalon.mobile，它可以更高效地运行于IE10等新版本浏览器中
没有任何依赖，不到5000行，压缩后不到50KiB
支持管道符风格的过滤函数，方便格式化输出
局部刷新的颗粒度已细化到一个文本节点，特性节点
要操作的节点，在第一次扫描就与视图刷新函数相绑定，并缓存起来，因此没有选择器出场的余地。
让DOM操作的代码近乎绝迹
使用类似CSS的重叠覆盖机制，让各个ViewModel分区交替地渲染页面
节点移除时，智能卸载对应的视图刷新函数，节约内存
操作数据即操作DOM，对ViewModel的操作都会同步到View与Model去
自带AMD模块加载器，省得与其他加载器进行整合。