後端修改數據通過使用sql語句實時修改前端某個控制項的值。
因為前端的數據如果都是從後端請求過來的話，後端直接更新數據就行了，一般來說後端的數據都是保存在資料庫中的，直接使用sql語句在資料庫中改對應的數據就可以了，所以後端修改數據通過使用sql語句實時修改前端某個控制項的值。
B. 前端限制了後端還要嗎
直接說結論，前端拿到後端的數據，不能直接用，還要再處理，在某些情況下是合理的，但是在題主寫的這個情況大概率是不合理的（因為不了解細節），正常來說，後端的介面設計應該是前端用著好使，並且一些需求發生改動後，前端只需要改一點點地方就能解決。
因為很簡單，前端的需求是渲染頁面，而後端的需求是給前端對應的數據。就比如說項目是一個新房子，前端就相當於裝修工人，而後端就相當於給裝修工人磚塊、瓷磚、地板的人。不可能所有的東西後端都需要給你弄好，一些磚塊你該劈成兩半就劈成兩半，這個不應該奢求後端做（雖然後端也能做）
簡單的說，後端更多的是提供泛用的介面，而不是每個介面都會定製化的給前端數據，這樣的話如果需求有修改，那麼前後端都需要修改了。
但是題主舉得例子就不一樣了，明顯是後端開發沒有做數據的過濾和整理，直接查了庫就返回回去了，這就變成了介面不規范的問題了。
正常來說遇到一些修改，前端可以改後端也可以改，並且以代碼或者架構的規范來看，那邊改都是合理的情況下，一般都是前後端商量商量哪邊更容易改就哪邊改，都是可以商量的事，這種改動大概率也花不了什麼時間。
C. 前後端分離方案以及技術選型
作者：關開發
一.什麼是前後端分離？
理解前後端分離大概可以從3個方面理解：
1. 交互形式
2. 代碼組織形式
3. 開發模式與流程
1.1 交互形式
前後端不分離
後端將數據和頁面組裝、渲染好了之後，向瀏覽器輸出最終的html；瀏覽器接收到後會解析html，解析引入的css、執行js腳本，完成最終的頁面展示。
前後端分離
後端只需要和前端約定好接收以及返回的數據格式（一般用JSON格式），向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後，進行頁面組裝、渲染，最終在瀏覽器呈現。
1.2 代碼組織形式
前後端不分離
在web應用早期的時候，前端頁面以及後台業務數據處理的代碼都放在一個工程下，甚至放在同一目錄下，前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高，前端不能獨立開發和測試，後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術（jsp），後端工程師還要會點前端技術，需要口頭說明頁面數據介面，才能配合完成開發。否則前端只能當一個「切圖仔」，只輸出HTML、CSS、以及很少量與業務邏輯無關的js；然後由後端轉化為後端jsp，並且還要寫業務的js代碼。
前後端分離
前後端代碼放在不同的工程下，前端代碼可以獨立開發，通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試；後端代碼也可以獨立開發，運行、測試，通過swagger技術能自動生成API文檔供前端閱讀，還可以進行自動化介面測試，保證API的可用性，降低集成風險。
1.3 開發模式與流程
前後端不分離
在項目開發階段，前端根據原型和UI設計稿，編寫HTML、CSS以及少量與業務無關的js（純效果那些），完成後交給後台人員，後台人員將HTML轉為jsp，並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後，將全部代碼打包，包含前端代碼、後端代碼打成一個war，然後部署到同一台伺服器運行。頂多做一下動靜分離，也就是把圖片、css、js分開部署到nginx。
具體開發流程如下：圖略
前後端分離
實現前後端分離之後，前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js（純效果那些），後端也同時根據原型進行API設計，並與前端協定API數據規范。等到後台API完成，或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API，或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行，或者前端先行於後端開發了。
具體開發流程如下：圖略
二、前後端分離的好處與壞處。
從上面3個方面對比了之後，前後端分離架構和傳統的web架構相比，有很大的變化，看起來好處多多。到底是分還是不分，我們還是要理性分析是否值得才去做。
從目前應用軟體開發的發展趨勢來看，主要有兩方面需要注意：
· 越來越注重用戶體驗，隨著互聯網的發展，開始多終端化。
· 大型應用架構模式正在向雲化、微服務化發展。
我們主要通過前後端分離架構，為我們帶來以下四個方面的提升：
· 為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
· 提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
· 完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
· 增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
那麼前後端分離有什麼不好的地方嗎？我目前是沒有想到，除非你說會增加前端團隊的配備，後端工程師會變的不全能。。。
二、前後端分離架構方案。
實現前後端分離，主要是前端的技術架構變化較大，後端主要變為restfull 風格API，然後加上Swagger技術自動生成在線介面文檔就差不多了。
對於目前用於前後端分離方案的前端技術架構主要有兩種：
· 傳統SPA
· 服務端渲染SSR
2.1 傳統SPA
傳統SPA指的是單頁面應用，也就是整個網站只有一個頁面，所有功能都通過這一個頁面來呈現。因為一個人的肉眼，某一個時間點看一個頁面，既然如此何必要不同功能做多個頁面呢？只保留一個頁面作為模板，然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎？確實如此，現在通過reac全家桶、tvue全家桶，模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。
單頁面應用的運行流程
1.用戶通過瀏覽器訪問網站url
2.單頁面的html文件（index.html）被下載到瀏覽器，接著下載html裡面引用的css，js。
3.css，js下載到瀏覽器完成之後，瀏覽器開始解析執行js向後端服務非同步請求數據。
4.請求數據完成後，進行數據綁定、渲染，最終在用戶瀏覽器呈現完整的頁面。
2.2 服務端渲染
服務端渲染的方案指的是數據綁定，渲染等工作都放在服務端完成，服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問，這不是又回到了前後端不分離的時代了嗎？答案是否定的，因為這里的服務端是用來執行前端數據綁定、渲染的，也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。
它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時，會先經過NodeJS服務端，由NodeJs去讀取前端頁面，並執行非同步後端API，獲取到數據後進行頁面數據綁定，渲染等工作，完成一個最終的html然後返回瀏覽器，最後瀏覽器進行展示。
服務端渲染應用的運行流程：
1.用戶通過瀏覽器訪問網站url
2.NodeJS服務端接收到請求，讀取到對應的前端html，css，js。
3.NodeJS解析執行js向後端API非同步請求數據。
4.NodeJs請求數據完成之後，進行數據綁定、渲染，得到一個最終的html。
5.NodeJs向瀏覽器輸出html，瀏覽器進行展示。
PS：其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後，我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。
看到這里，你是否又有疑問，為什麼要這么麻煩搞服務端渲染呢？
2.3 SPA與服務端渲染方案對比
SPA的優點是開發簡單，部署簡單；缺點是首次載入較慢，需要較好的網路，不友好的SEO。
so，以下就是使用服務端渲染的理由了（摘取vue官方說法）：
與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比，伺服器端渲染 (SSR) 的優勢主要在於：
· 更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
請注意，截至目前，Google 和 Bing 可以很好對同步 JavaScript 應用程序進行索引。在這里，同步是關鍵。如果你的應用程序初始展示 loading 菊花圖，然後通過 Ajax 獲取內容，抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說，如果 SEO 對你的站點至關重要，而你的頁面又是非同步獲取內容，則你可能需要伺服器端渲染(SSR)解決此問題。
· 更快的內容到達時間 (time-to-content)，特別是對於緩慢的網路情況或運行緩慢的設備。
無需等待所有的 JavaScript 都完成下載並執行，才顯示伺服器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗，並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言，伺服器端渲染 (SSR) 至關重要。
使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：
· 開發條件所限。瀏覽器特定的代碼，只能在某些生命周期鉤子函數 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程序中運行。
· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同，伺服器渲染應用程序，需要處於 Node.js server 運行環境。
· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集)，因此如果你預料在高流量環境 (high traffic) 下使用，請准備相應的伺服器負載，並明智地採用緩存策略。
以vue為例，實施服務端渲染可以查看官方指南： https://ssr.vuejs.org ，或選擇Nuxt.js
2.4 預渲染技術
如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。
如果你使用 webpack，你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上，作者是 Vue 核心團隊的成員。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前後端分離技術選型
- artTemplate + bootstrap（不推薦， 不算完全前後端分離）
- vue全家桶（推薦）
- react全家桶 （推薦，生態全）
D. 一個介面返回contenttype=text/plain的數據，在前端怎麼處理
springboot項目，在接收text/plain格式的時候，無法通過@requestBody得到請求中的json信息，需要對請求中的參數進行解析。
異常 type 'text/plain;charset=UTF-8' not supported。
/**
* 解析text/plain格式請求中的json
*
* @param request
* @return
*/
public static String fetchPostByTextPlain(HttpServletRequest request) {
try {
BufferedReader reader = request.getReader();
char[] buf = new char[512];
int len = 0;
StringBuffer contentBuffer = new StringBuffer();
while ((len = reader.read(buf)) != -1) {
contentBuffer.append(buf, 0, len);
}
return contentBuffer.toString();
} catch (IOException e) {
e.printStackTrace();
log.error("[獲取request中用POST方式「Content-type」是「text/plain」發送的json數據]異常:{}", e.getCause());
}
return "";
E. 我在後端與前端交互是用json格式進行交互，那麼我的每個返回到前端的方法都有一個固定的格式
你可以寫一個介面，所有的service來繼承這個介面，
publicinterfaceIService{
voidtext()throwsException;
}
F. 寫給產品經理之前端是如何展示後端數據的
移動互聯網的迅猛發展讓移動APP呈現出爆發之勢，這兩年更是移動開發程序員的春天。
今天的互聯網上充斥著產品與技術的撕逼。也許你會問產品經理到底要不要懂技術？由此引申出，產品經理到底要不要懂設計？產品經理到底要不要懂運營？產品經理到底要不要懂市場？產品經理到底要不要懂業務？這所有問題的來源都是大家對於產品經理的工作認識不一致。
每個人心中都有一個產品經理的定義，產品經理在技術方面更多的是去統籌和規劃。不是畫畫圖寫寫文檔就可以了。這裡面更多的需要的是對邏輯的梳理和拆分。
例如很簡單的一個app內嵌發紅包的活動，產品經理需要確定整個活動的流程。從用戶進入頁面的那一瞬間就應該被產品經理掌控。他的每一個步驟，每一個操作會帶來什麼結果，有哪些變數會導致活動進程失敗，這些都要產品去考慮。等到活動邏輯和過程全部梳理完成，下面就要進行拆分了。還是以發紅包為例，紅包中金額是客戶端寫死還是服務端進行計算，紅包領取資格需要服務端返回幾種結果，每種結果對應客戶端的提示是什麼，用戶領取紅包以後服務端需要記錄那些信息（帳號，uid，領取時間，金額，是否使用等），客戶端哪些地方需要加入計數器進行數據統計。總結起來其實就是，產品經理需要根據開發的每一個環節，將所有內容分類整理，並分發給不同部分的開發進行研發。最後，還需要給測試准備好check list，當測試按照check list測試完成以後，才可以上線。
以上種種都需要產品對前端如何顯示後端數據有一個清晰的認識才能規劃好數據如何展示。是APP寫死呢還是後台返回，在用戶任務進行的時候有哪些可能case。只有搞清楚這些，產品才能在實際的開發中掌握好整個項目的流程與進展，才能不被開發給糊弄。
簡單的說，前端僅僅將後端返回的數據展示在頁面上，不做過多的邏輯處理。前端需要關心的是，數據如何更好的展示出來，頁面效果如何做出來，以及其性能問題。
而後端就是負責對這些數據進行處理，提供給前端展示。
前端一般有H5、android、ios等多端界面。數據不要輕易寫死在前端裡面，不然到時候三端都要修改，費時費力。而將這些變化多數據讓後端進行處理，前端將這個數據取出來顯示出來就行了。
舉個例子吧，下圖是一個美團app首頁團購的展示效果
上方美食等8個icon一般為固定展示欄目，非特殊情況不會修改。那麼前端一般是寫死在app中，等到需要更新的時候更新app即可。
而下方猜你喜歡是一個列表，該列表數據經常變化，數據寫在服務端維護，app取出數據進行展示即可。
首先，前段對頁面的展示是分兩步走的。
第一、在本地繪制好界面，當然此時未連api會填充一些假數據，或寫一些默認值。
第二、連api進行數據獲取，將數據填充進界面。
既然如此，咱們簡單看下前端拿到的數據到底長什麼樣的吧。
現在前端獲取到的數據基本是json數據。
不需要特別懂裡面每一個的含義，只需要知道，前端通過"title"這個鍵名(key)就可以拿到"合輯護甲"這個值(value)。 "title": "合輯護甲" 這一整個就是俗稱的一個欄位。通過該欄位前端就可以獲取到列表的標題了。當然這個列表只是簡單的展示用，還有諸如圖片地址、優惠信息、已售份額等信息沒有提供，這就是缺少欄位的情況。
前後端就是通過這樣的一個定義獲取/傳遞數據的。
考慮到後期拓展、需求變更等，一般來說，涉及到計算的、可能有變動的，一律不要讓前端來弄。
還是剛才那個例子，在剛才那個列表中有一個「立減5元」的橙黃色tag。
這個tag信息，如果考慮不充分，比如說，後端只提供一個數字5，然後前端在其頁面寫死「立減x元」，x為填入後端提供的數字，顏色固定為橙黃色。這個如果需求不修改還好，如果後期需要新增一個「滿20減5元」的紅色tag不傻眼了嗎？
到時候只能通過升級app來解決，而且不升級的老用戶將永遠看不到這個紅色的tag。
所以說，考慮到程序的可復用和拓展性，需要產品將後期可能新增或變更的需求考慮好，和前後端進行溝通，讓前後端設計好實現，盡量降低程序的耦合和硬編碼。這才能使一個產品更加健壯以及讓苦逼的程序猿少加班的關鍵。
那麼剛才那個tag的需求如何設計才合理呢？
首先是tag顯示文字，全權由後端提供，可以是多個欄位，由前端進行拼接。然後是tag的顏色，提供幾種樣式讓前端判斷是一種可行的辦法，但是直接提供tag的色值給前端的這種方式無疑給前端展示增加了無限的可能。
是不是也要增加一個tag形狀的欄位呢？
俗話說，過猶不及。tag形狀這種東西真的很少變更，欄位太多無疑會增加開發的時間成本，而且會讓人有一種捨本逐末之感。
前端獲取到後端數據後，如果前端不主動刷新重新請求數據的話，這個頁面的數據在該頁面銷毀前會一直保持不變。
如何理解？
首先，第一次進入一個頁面，該頁面數據為空或默認數據。此時前端會鏈接api請求數據。數據請求完成後，填充進頁面。那麼本次聯網請求就完成了，在前端不進行二次數據請求之前，該頁面會一直保持本次請求的數據。也就是說，就算服務端修改了數據，前端此時是不能事實的進行更新的，因為我前端不知道你數據更新了。
那麼在這個需要實時更新頁面數據的時候和前端講這種需求會被前端直接回絕：「做不了」。這個時候產品咋辦，怪怪妥協？最後背鍋的還是自己，而且自己也不知道是真做不了還是假做不了。
實時刷新也不是不能做，只是做的成本略高，需要和後端進行配合，像微信聊天一樣和後端進行長連接(socket)，這樣服務端數據變更前端就知道數據變更了。
當然如果稍懂頁面刷新機制的話，可以要求前端在適當的時機進行頁面刷新，如在頁面可見的時候進行刷新，這樣用戶每次看到的都是最新的數據。也可以讓用戶主動刷新，如新增刷新功能。
產品懂技術這件事情，不僅會降低和開發同學溝通時的難度和被歧視風險，還會提升在面對開發同學意見時的判斷力，會降低被技術團隊忽悠的幾率。同時，在需要向上級解釋技術原因導致變更的情況下，也會有助於說服老闆。
「聞道有先後，術業有專攻」，要相信自己所接觸的開發團隊是專業的，靠譜的，相信開發團隊為實現需求所做出的技術方案是合理的，最優的。如果有質疑，可以加深溝通，以合適的方式提出自己的質疑。這里要補充一句的是，這個信任過程是需要建立的，也是會根據團隊的表現不斷變化的；同理，其實團隊對於產品經理的信任度也是一樣的情況。
吐槽是沒有意義的，關鍵還是要解決問題。如果覺得產品經理不靠譜，那麼有沒有進行過深入的溝通？如果覺得開發不好溝通，那麼有沒有進行過了解，不好溝通的原因在哪裡？如果當事人本身確實不可溝通，那麼有沒有考慮和對方的老闆溝通，或者通過自己的老闆如實反映情況？吐槽是最容易的，解決問題反而會很難。
G. 前端通過介面提速了後端數據，怎麼讓這些數據變成json格式呢
一般不存在前端給後端介面的情況，幾乎都是後端給前端介面，所謂介面就是可以通過服務端部署的機器提供出來的URL地址進行動態的數據交互。通常的工作流是後端跟前端協商定義數據介面格式（一般就是JSON格式）形成文檔，後端實現介面，前端做靜態的mock（可以是直接在頁面的JS拼假數據或者通過JSON server按照真實調用服務的方式集成），後端實現服務介面，兩邊都完成後集成聯調。現在有swagger 或者 apiairy 等工具可以更簡化這個過程
H. 後端的的數據格式為數組 前端怎麼傳參
將數據以json格式傳給前端：
function generateDtb() {
//寫入
var txtName = document.getElementById("txtName").value;
//創建數組
var dtb = new Array();
//通過循環把數據寫入到數組並返回
for (var i = 0; i < firstGroup.length; i++) {
var row = new Object();
row.Name = txtName;
row.fullMoney = firstGroup[i].value;
row.discount = secondGroup[i].value;
dtb.push(row);
}
return dtb;
}
把數組轉換成json串傳入到後台：
$(function () {
//點擊botton1
$("#lbtnOK").click(function () {
var url = "DiscountManger.aspx?ajax=1";
var dtb = generateDtb();
// var strName = document.getElementById("txtName").value;
if (dtb == null)
{ }
else {
//序列化對象
var postdata = JSON.stringify(dtb);
//非同步請求
$.post(url, { json: postdata }, function (json) {
if (json) {
jBox.tip("添加成功！", "提示");
location.reload();
}
else {
jBox.tip("添加失敗！", "提示");
location.reload();
}
}, "json")
}
});
});
在後台的操作：
首先判斷是否需要傳輸數據
if (!IsPostBack)
{
//判斷是否非同步請求
if (Request.QueryString["ajax"] == "1")
{
ProcessRequest();
}
在這里進行對數據的處理：
/// <summary>
/// 處理非同步請求
/// </summary>
private void ProcessRequest()
{