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，减少风险），也不需要担心未来的维护工作!