從邏輯解偶到物理解耦再到先後端分離

 

邏輯解偶：

      MVC是一個表現層的架構模式，它把咱們的Web應用劃分紅模型，視圖，控制器三部分。從邏輯上解耦了系統的業務邏輯和表現邏輯。但問題在於MVC的各部分並無一個嚴格的定義，去指導咱們何時使用M何時應該使用V，這些判斷都取決於咱們以往的項目經驗，因此對於工做應驗很少的人來講要徹底理解而且合理應用並不容易，甚至可能還會引入沒必要要的複雜性。

先後端耦合：

      因爲模版文件和靜態demo由項目中不一樣的角色來維護，前端修改demo，須要通知後端去同步模版，相應的模版變動也要通知前端去同步demo。如過二者不一樣步就會產生問題。另外後端套vm模版須要修改HTML，後端不擅長作這些事情，就比較容易出問題。工做可能會遇到這樣的場景，前端同窗把靜態demo交付給開發，開發拿到demo套後端模版，接着進行先後端聯調。聯調完成後，一直運行的很好。某天后端同窗來過來講界面有問題，通過反覆溝通，花費時間排查問題。發現原來是修改vm模版文件的時候HTML標籤嵌套錯了。

先後端分離：

       開發中分離關注點有助於屏蔽項目的複雜性，下降維護成本。前端和後端的分工協做就是爲了更好的實現關注點分離。然而因爲vm模版這塊職責不清，當前這種協做方式致使先後端耦合較多。經過先後端分離，前端關注界面(視圖)和界面交互（控制器）的實現，後端關注業務功能和持久化的實現。後端經過接口的形式提供數據給前端使用，後端不用關心數據怎麼顯示在那顯示。前端不關心數據從哪來的好比數據庫，緩存仍是其餘什麼地方，也不關心數據是怎麼來的，好比通過了那些複雜的邏輯處理。專業人員作自身擅長的領域，使得項目中表現和業務邏輯的物理解耦，進一步提升了先後端開發人員犯錯門的門檻，也能夠有效提高項目的可維護性和不一樣角色之間協做溝通效率。

怎麼實施：

   若是讓前端開發參與到java工程中接手項目中的視圖和控制器這個明顯不符合實際。 javascript，是每一個前端前端工程師的必備技能，有不少成熟的基於nodejs的web mvc開發框架。能夠很容的幫我實現控制器和和視圖的功能。我認爲前端工程師不等於瀏覽端器工程師，和界面、界面交互相關的技術實現都應該屬於前端範疇。

 

 

 

 

和後端約定數據接口面向接口開發，

 

分離關注點：

bui遷移的 vmcommon 的問題就不存在


痛點是是什麼，問題。
要不要作一個node web 框架
問題：數據經過http傳輸會不有性能問題
解決當前的ued kpi（擎天柱）仍是先後端分離
咱們要作先後端分離嗎：
先後端分離，midway