本發(fā)明涉及一種MVC管理平臺設計方法，特別涉及一種基于RESTful接口的前端MVC管理平臺設計方法。

背景技術：

隨著數(shù)字智能化時代的到來，伴隨著用戶終端訪問互聯(lián)網(wǎng)資源的需求的逐漸增長，海量的頁面的訪問已經成為迫切的需要，而且用戶在進行頁面訪問時希望具有較高的訪問速度?，F(xiàn)階段頁面的訪問大多是先由用戶在瀏覽器的地址欄輸入一個URL地址，并將整個URL地址送至服務器中處理，但是如果用戶在訪問頁面多或者URL地址較長的情況下，服務器會出現(xiàn)反應很慢，在服務請求高峰期服務器可能長時間都沒有響應造成用戶所看到的是瀏覽器圖標一直在旋轉而沒有內容展現(xiàn)，直到服務器響應了之后，才會慢慢的呈現(xiàn)數(shù)據(jù)內容，此時用戶在進行頁面訪問時導致訪問效率不高，影響用戶瀏覽體驗。

技術實現(xiàn)要素：

本發(fā)明為了克服上述現(xiàn)有技術的不足，提供了一種基于RESTful接口的前端MVC管理平臺設計方法，本方法能夠大大提高頁面的訪問效率，而且可靠性高、用戶的體驗效果好。

為實現(xiàn)上述目的，本發(fā)明采用了以下技術措施：

一種基于RESTful接口的前端MVC管理平臺設計方法包括以下步驟：

S1、操作人員在B/S結構的瀏覽器中輸入URL地址；

S2、所述URL地址由前端MVC管理平臺中的控制器層進行處理；所述控制器層對所述URL地址進行解析得到特定的變量或變量組；

S3、所述瀏覽器將得到的所述變量或變量組發(fā)送至B/S結構的服務器，所述服務器收到所述變量或變量組后，生成前端MVC管理平臺所要求格式的數(shù)據(jù)文檔；

S4、所述前端MVC管理平臺中的模型層接收所述數(shù)據(jù)文檔，并將所述數(shù)據(jù)文檔填充到所述模型層中的相應模型的屬性中，即使所述模型實例化；

S5、實例化后的模型被發(fā)送到所述前端MVC管理平臺中視圖層，經所述視圖層處理后在顯示屏上顯示。

優(yōu)選的，所述變量或變量組是由所述控制器層根據(jù)所述URL地址的根目錄配置而成。

優(yōu)選的，所述變量或變量組通過RESTful請求的方式發(fā)送至B/S結構的服務器。

進一步的，使用AngularJS編寫前端MVC管理平臺的代碼。

本發(fā)明的有益效果在于：

1)、本發(fā)明在瀏覽器中輸入URL地址后，由前端MVC管理平臺中的控制器層對所述URL地址進行解析得到特定的變量或變量組發(fā)送至服務器，服務器收到所述變量或變量組后，生成前端MVC管理平臺所要求格式的數(shù)據(jù)文檔，所述前端MVC管理平臺中的模型層接收所述數(shù)據(jù)文檔，并將所述數(shù)據(jù)文檔填充到所述相應模型的屬性中，即使所述模型實例化；實例化后的模型被發(fā)送到所述前端MVC管理平臺中視圖層，經所述視圖層處理后在顯示屏上顯示。所述服務器僅在步驟S3中進行處理，而且將整個URL地址解析成為變量或變量組，因此本方法能夠大大提高頁面的訪問效率，而且本發(fā)明的可靠性高，用戶的體驗效果較好。

附圖說明

圖1為本發(fā)明的系統(tǒng)架構圖；

圖2為本發(fā)明的前端MVC結構模型圖；

圖3為本發(fā)明的RESTful接口數(shù)據(jù)流圖。

具體實施方式

下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

如圖1所示，一種基于RESTful接口的前端MVC管理平臺設計方法包括以下步驟：

S1、操作人員在B/S結構的瀏覽器中的地址欄輸入或超鏈接一串URL地址，例如http://www.resource.com/mission。

瀏覽器指的是用戶使用訪問網(wǎng)頁的軟件，前端MVC指的是一種網(wǎng)頁設計模式，前端MVC充分利用了瀏覽器的存儲能力和計算能力，大大減輕了服務器的工作。

S2、所述URL地址由前端MVC管理平臺中的控制器層進行處理；所述控制器層對所述URL地址進行解析得到特定的變量或變量組，如果所述控制器層檢測到URL地址路徑是在服務器根目錄下/mission，就跳轉到http://www.resource.com/buzPage/missions/list.html頁面。此時，瀏覽器頁面先跳轉到http://www.resource.com/buzPage/missions/list.html這個模板頁面，所述模板頁面只是有一個HTML的結構，并沒有實際數(shù)據(jù)，而實際數(shù)據(jù)是當瀏覽器開始加載這個模板頁面那一刻開始請求的。

控制器層對所述URL地址進行解析，具體的，URL返回全部服務列表，如service1,service2,service3,service4等，URL地址為：/services/5，服務器接收到所述URL地址后會返回ID為5的服務即返回service5。

S3、所述瀏覽器將得到的所述變量或變量組發(fā)送至B/S結構的服務器，所述服務器收到所述變量或變量組后，生成前端MVC管理平臺所要求格式的數(shù)據(jù)文檔；

服務器返回service5后，會按照service的數(shù)據(jù)結構序列化一個字符串，若service的數(shù)據(jù)結構為id，name，startTime，initName，生成前端MVC管理平臺所要求格式的數(shù)據(jù)文檔的過程就是service5的實例屬性是id為5，name為service5，startTime為2016-11-1109:00:00，initName為Service5_init1；

service5生成的結果為：{id:5，name＝'service5'，startTime:'2016-11-1109:00:00'，initName:'Service5_init1'}

S4、所述前端MVC管理平臺中的模型層接收所述數(shù)據(jù)文檔，并將所述數(shù)據(jù)文檔填充到所述模型層中的相應模型的屬性中，即使所述模型實例化；

S5、實例化后的模型被發(fā)送到所述前端MVC管理平臺中視圖層，經所述視圖層處理后在顯示屏上顯示。

所述變量或變量組是由所述控制器層根據(jù)所述URL地址的根目錄配置而成。

配置的具體操作過程例如配置了/services/{ID}，表明/sevices/5中的5就對應ID，代表獲取id為5的服務的詳細信息。配置完成后會生成一個配置文件，這個配置文件最后存儲在瀏覽器中，最后瀏覽器讀取了這個配置文件就會按照這個規(guī)則解析URL。

用戶通過視圖層觸發(fā)事件給控制層，控制層調用后臺RESTful接口傳輸數(shù)據(jù)給前端的模型層，模型接收到數(shù)據(jù)之后通知控制層，控制層重新繪制視圖層從而把最新的數(shù)據(jù)或者操作結果呈現(xiàn)給用戶。

如圖2所示，此圖詳細展示了MVC三層互相調用的協(xié)同合作關系。其中，M是Model，模型層，是抽象系統(tǒng)需要展示的內容和操作的一類屬性和事件；V是View，視圖層，用來呈現(xiàn)界面給用戶查看和操作；C是Controller，控制層，是用來感知視圖層用戶操作，控制層接受到用戶操作事件之后調用后臺RESTful接口進行數(shù)據(jù)獲取和相關操作，其結果返回被模型層接收，接收之后，控制層通知視圖層渲染最新的數(shù)據(jù)，于是視圖層就向用戶呈現(xiàn)了最新的數(shù)據(jù)和操作結果。

如圖3所示，此圖展示了RESTful接口中客戶端和服務器端通信的過程。其中，客戶端向服務端發(fā)送請求，服務端返回客戶端以結構化的狀態(tài)和數(shù)據(jù)。在這里客戶端本身的是維護了狀態(tài)的，這里的狀態(tài)包括某些會話、應用、緩存等。RESTful接口的服務端是不維護狀態(tài)的，RESTful接口的這種特性使得它可以更加方便的部署到多臺服務器上，因此不會產生會話丟失的問題，并且保證了同樣的請求一定返回相同的數(shù)據(jù)和結果。

本發(fā)明改變了傳統(tǒng)的頁面加載流程，使得用戶在點擊超鏈接之后就能看到結果頁面，采用異步的方式去服務端獲取數(shù)據(jù)，提高了用戶體驗，同時減輕了服務器端和網(wǎng)絡輸入輸出的壓力。

綜上所述，本發(fā)明極大地提高了頁面的訪問效率，而且本發(fā)明的可靠性高，用戶的體驗效果較好。