JPA学习笔记-EJB-04JPA关联映射总结--6
TeamVO
| package mangerTeam.vo;
import java.io.Serializable; import java.util.Set;
import javax.persistence.CascadeType; import javax.persistence.Column; import javax.persistence.Entity; import javax.persistence.FetchType; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType; import javax.persistence.Id; import javax.persistence.OneToMany; import javax.persistence.Table;
/** * 俱乐部实体 * @author 刘岩 */ @Entity @Table(name = "team") public class TeamVO implements Serializable {
@Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "id", unique = true, nullable = false) private Integer id;
@Column(name = "teamName") private String teamName;
@OneToMany(cascade = CascadeType.REFRESH, fetch = FetchType.LAZY, mappedBy = "teamVO") private Set<PlayersVO> players;
public Integer getId() { return id; }
public void setId(Integer id) { this.id = id; }
public String getTeamName() { return teamName; }
public void setTeamName(String teamName) { this.teamName = teamName; }
public Set<PlayersVO> getPlayers() { return players; }
public void setPlayers(Set<PlayersVO> players) { this.players = players; }
} |
在此类中注意如下片段
| @OneToMany(cascade = CascadeType.REFRESH, fetch = FetchType.LAZY, mappedBy = "teamVO") private Set<PlayersVO> players;
|
即是声明和运动员一对多的关系
cascade = CascadeType.REFRESH：级联更新，当俱乐部信息更新的时候相应俱乐部中的运动员也更新，当俱乐部被删除的时候，不能把运动员也从数据库中删除了吧，所以这里只是REFRESH的时候才会级练到运动员，其他的操作不必理睬运动员。
mappedBy = "teamVO"：表示teamVO在双方关系中属于被维护的一方，那么PlayersVO就是维护方，那么造成一个后果就是只能PlayersVO去更新外键，PlayersVO与TeamVO之间的外键关联关系是PlayersVO说了算的。结合实际就是，“宁教老子负公司，休教公司负老子”，老子不爽了可以走人、你公司不爽老子还得继续忍着吧……
具体业务代码和N VS M的差不多，在此不再赘述。
1. 1 VS 1映射总结
一对一的映射模型如下描述：
一个商品实体VS 此商品的详细信息实体。
每一个商品都唯一对应一个详细信息的描述，商品实体可以没有详细信息实体。
此处我们只给出代码片段
Products（商品实体）
|
/** * Products */ @Entity @Table(name = "products", catalog = "tgweb") public class Products implements java.io.Serializable {
@Id @GeneratedValue(strategy = IDENTITY) @Column(name = "id", unique = true, nullable = false) private Long id;
/** * 详细信息 * */ @OneToOne(optional = true, cascade = CascadeType.ALL) @JoinColumn(name = "productsMessageInfo_ID") private ProductsMessageInfo productsMessageInfo;
/** default constructor */ public Products() { }
…………………省略…………………
public ProductsMessageInfo getProductsMessageInfo() { return productsMessageInfo; }
public void setProductsMessageInfo(ProductsMessageInfo productsMessageInfo) { this.productsMessageInfo = productsMessageInfo; }
} |
说明：
@OneToOne(optional = true, cascade = CascadeType.ALL)
表示和商品详细信息是一对一的关系，级联操作是当商品所有的持久化操作都会关联到详细信息的操作，详细信息可以为空。
@JoinColumn(name = "productsMessageInfo_ID")
在商品表中建立一个外键用于维护和商品详细信息的关系。字段名称为productsMessageInfo_ID。
注意：因为在商品中所有的操作都会影响到商品详细信息，所以更新商品的时候应该先将详细信息查询出来后再保存，和1 VS N一样的道理。
总结：
1. 感觉在做实体操作（尤其是更新的时候），往往都需要将原始体的关联实体临时保存到一个地方，之后还得原封不同的赋值给新实体，之后再保存。这就是级联操作的影响。要不将所有的实体属性全部加载到展示层上，View的压力比较大。
2. 在做建模设计的时候，尤其以多对多映射最为复杂、查询效率也是最低的，偶尔为了解决一个比较复杂的业务，可能要借助中间模型来做N VS M的桥梁。
3. 有效地利用Java集合映射属性，List、Set、Map等不同特点来建模。在未确定使用Set或者List的时候可以使用他们的父类Collection，Set里面的元素不能重复，这个可以通过Set的equal和hashcode方法区分是否是同一条实体记录。List是有顺序的、并且里面元素可以重复。
4. 一般都是1 VS N、N VS 1和N VS M的需求比较多，而1 VS 1相对于前几者相对来说业务需求比较少。
5. 建模、设计领域模型、类关系思考需要的时间肯定远远大于编程的时间。
6. 级联策略完全由系统的业务需求而定，没绝对的正确，也没有绝对的错误，级联策略的选择是在一个折中的情况下而制定的，有可能业务层需要多些几行代码，有可能在视图层多写一些代码来维护原有的关联关系，这个完全取决于业务。
7. 在笔者的这份经验总结中只是关联映射的一部分实现而已，像双向一对一、单向一对多、单向多对一并没有总结在这份文档中，因为暂时并无此业务需求，每每发现做单向关联设计的时候，还是双向的比较好，双方都能找到对方。以后有机会一定补上。
如果有什么不正确的希望不吝指正。