① 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類項目的組件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。