2017-06-03 107 views
2

我有一個關於與thymeleaf和關係管理使用springboot的問題。Springboot關係管理

我有一個需要充分的雙向三個對象:

OBJ1(多) - TO - (一)OBJ2(一) - TO - (多)OBJ 3

他們設置爲:

public class Obj1 { 
@Id 
private long id; 
@ManyToOne(cascade=CascadeType.ALL) 
private Obj2 obj2; 

public class Obj2 { 
@Id 
private long id; 
@OneToOne 
private User planUser 
// Other fields 
@OneToMany(mappedby = obj2) 
private List<Obj1> obj1; 
@OneToMany(mappedby obj2) 
private List<Obj3> obj3; 

public class Obj3 { 
@Id 
private Long id; 
@ManyToOne 
private Obj2 obj2; 

在視圖方面,有一個名爲view1的頁面,用於填充Obj1。這工作。

有一個名爲view2的另一個頁面: 1. OBJ1顯示一些基本的細節 2.填充/更新OBJ 2和OBJ 3

的問題是如何提交視圖2更新/創建OBJ 2和OBJ 3。

我試圖讓控制器去呼籲OBJ1服務方法:

@Override 
@Transactional 
public Obj1 associateObj1ToObj2(Long Obj2Id, Obj1 newObj1) { 
    final Obj2 obj2 = ojbj2Repository.findOne(obj2Id); 
    obj2.getObj1().add(newObj1); 
    newObj1.setObj2(obj2); 
    return obj1Repository.save(newObj1); 
} 

問題:

  1. 即使我有@Post形式控制器obj2Repo.save (obj2)當我嘗試在associateObj1ToObj2中調用它時 - 應該保存的值(如userPlan)不是。爲什麼?
  2. 在上述情況下,單個根對象是否可以並且應該爲多個頁面提供服務? (建議的替代方案顯然是創建一個混合類用於支持頁面view2 - 鏈接到git示例是偉大的(這就是所謂的DTO))。
  3. 是否糾正springboot不會處理關係設置,至少在一個孩子的孩子需要被更新的情況下)
  4. 什麼是Hibernate的Session的生活嗎?

注意:許多關係真的應該叫幾個 - 對關係的藏品幾乎總是人數少於10

這個答案似乎是有一定的關係:Could not initialize proxy - no Session

+0

IMO,你最好一次問一個問題。如果你花時間提供一個[最小,完整,可驗證的例子](/ help/mcve) –

+0

這將是非常棘手的,因爲我會很難看到你在做什麼,將需要重複項目,然後重構和混淆。 –

+0

@AndyWilkinson做這個幫助:https://github.com/bigalnz/mvce/tree/master –

回答

3

我正想在這裏討論使用對話的基於支持框架的雙方,但是,我認爲這在事後看來是無關緊要的。雖然這些框架可以幫助處理視圖/控制器/域對象一致性所需的樣板文件,但我不認爲應該如何設計控制器和視圖來與用戶交互。

我會說大多數開發人員經常採取發送他們的實體bean到視圖的立場作爲支持bean表示。對於小型非複雜的imo遊戲項目來說,這些項目就足夠了,但通常這種方法在實體關係或UI佈局變得複雜時開始崩潰。

通過使用非實體作爲您的視圖的後備bean,您可以讓您的UI和視圖有機地增長,而不受制定數據庫表和持久性關係的決策和選擇的約束。這也意味着您可以利用數據庫模式設計選擇,而不會影響您在UI中如何佈局和與用戶交互。在重構代碼或通過UI更改改善用戶體驗期間,這變得非常有用。

即使我有@Post形式控制器obj2Repo.save(OBJ 2)當我試圖回憶起來associateObj1ToObj2-應該已經保存(如userPlan)的值都沒有。爲什麼?

難道形式實際上該信息發送回在後?

讓我們假設我們有一個非常簡單的對象:

class SomeEntity { 
    private Integer id; 
    private String name; 
    private String address; 
    private List<String> nicknames; 
} 

如果所有的形式允許爲用戶更改其地址,但形式實際上並沒有給我們回值name,它會當我們檢查控制器中的SomeEntity實例時,請將其設爲空。那真的是我們想要的嗎?如果你有關係,也會發生同樣的情況。如果表單實際上沒有將我們的暱稱列表發回給我們,那麼這種關係也將是空白的。

對我來說,這凸顯爲什麼支持豆意見最終應代表視圖的使用情況,並不僅如此。我們確切地知道視圖需要和返回哪些字段,並且我們管理數據的生命週期,而不依賴於我們的實體模型在我們的應用程序和持久性提供者的角度上被認爲是有效的數據。

在上述情況下,單個根對象是否可以並且應該有多個頁面? (建議的替代方案顯然是創建一個混合類用於支持頁面view2 - 鏈接到git示例是偉大的(這就是所謂的DTO))。

這是一個簡單的喜好設計選擇。一個視圖的單個後臺bean非常好。我們有理由認爲,雖然多個後備豆:

  1. 對待你的觀點爲更小的塊組成。
    這允許代碼在其他UI佈局中重用這些組件。
  2. 隔離可變VS不變的表單屬性。

通常我更喜歡(1)作爲默認選擇。我主張使用(2)的唯一情況是視圖具有相當數量的只讀字段給用戶上下文信息,並且它們只能改變總體屬性數量的一小部分。

是否糾正springboot不會處理關係設置,至少在一個孩子的孩子需要被更新的情況下)

這不是一個springboot關注。正如我之前提到的,這種情況發生的很多原因取決於其他因素。

  1. 什麼數據在窗體中被序列化並反過來被髮送回控制器。
  2. 表格是如何組織的,它是否被正確地序列化。
  3. 您是否在使用對話框架/配置。

什麼是Hibernate會話的生命?

這取決於您的配置設置。

春天開機後允許使用的OpenSessionInViewOpenEntityManagerInView過濾器Hibernate會話的生命週期延伸到web請求已經結束點。在我看來,除了簡單的原型外,你不應該使用這個,因爲它帶有它自己的問題,包括性能和意外的插入,更新和基於糟糕的假設或代碼的刪除。

+0

非常有幫助 - 我對冬眠魔法的細節感到困惑 –