『壹』 有哪些主流的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模塊載入器，省得與其他載入器進行整合。