1. 一個web項目前後端分離,前端工程師需要掌握哪些
1、先理清業務流程
2、定義前後端開發的介面規盯扒范。比如json的格式，url的格式
3、定義介面文檔，這里的介面文檔一般首雹就是對應後台的實體reqVo（調用後台介面<控制器>訪問的實體）和返回給前台的respVo（前台調用介面的返回的實體）者則帆。注意一般respVo都會有在後台做一個統一的處理為ResultVo（這個規范在2中要定義好，比如：錯誤碼，錯誤描述，請求的url，請求時間，以及實體T<這個實體才是真正的respVo和業務相關,這個一般都是實體>）
4、定義介面文檔是在了解業務流、數據流基礎之上完成的。有了這個介面文檔（其實就是定義實體的過程和對應的json）前後端的開發基本按照這個文檔去開發。介面文檔會有版本迭代，一般放到svn上，供所有開發人員閱覽
5、現在一般系統用到的資料庫都不會是單純mysql了。還有redis，mongo、es等。這些個人感覺都是在十分了解業務的情況和系統架構下去設計的。後台運用這些工具去完成介面功能的實現已經系統功能和性能的實現。這個和介面文檔先後順序還真不好說，個人覺得都可以。
6、業務流-數據流-資金流。去了解和設計系統。
2. vO dto為啥不能注入
因為他們不是注入函數。
VO（viewobject/valueobject）表示層對象為前端展示的數據，在介面數據返回給前端的時候需要轉成VO。DTO（DataTransferObject）數據傳輸對象，是在服務間的調用中，傳輸的數據對象。都不是注入函數，所以無法注入。
用戶姓名name、用戶密碼password、用戶的年齡age。首先資料庫層獲取PO數據包含這三個欄位的數據，可是password不應該暴露出去，怎麼做呢，在發送給服務層的時候做一次處理，轉成只有name和password的DTO，這樣就能減少出數據的傳輸，同時將name可以改為username，就可以保證資料庫結構的安全。
3. 如何利用VO層操作資料庫
一、PO:persistant object 持久對象,可以看成是與資料庫中的表相映射的java對象。使用Hibernate來生成PO是不錯的選擇。
二、VO:value object值對象。通常用於業務層之間的數據傳遞，和PO一樣也是僅僅包含數據而已。但應是抽象出的業務對象,可以和表對應,也可以不,這根據業務的需要.
有一種觀點就是：PO只能用在數據層，VO用在商業邏輯層和表示層。各層操作屬於該層自己的數據對象，這樣就可以降低各層之間的耦合，便於以後系統的維護和擴展。如果將PO用在各個層中就相當於我們使用全局變數，我們知道在OO設計非常不贊成使用全局變數。
但是每次都得進行VO-PO的轉換，也確實很煩。我覺得有時候也可以在某個商業邏輯或者表示層使用PO，此時在這個商業邏輯的過程中PO的狀態是不發生變化的，比如顯示一條商品詳細信息的商業邏輯。
在開發過的項目中，規模都很小，我一直都把PO當VO用，因為PO確實很方便，結合Hibernate的DAO，我使用JAVA的集合對象作為值傳遞的載體，當然Struts也是我的不二之選。
我認為：在一些直觀的，簡單的，不易發生變化的，不需要涉及多個PO時，傳遞值還是使用PO好，這樣可以減少大量的工作量（也就意味著減少bug，減少風險），也不需要擔心未來的維護工作!