使用Wicket + Spring + Hibernate的三層分層應用程序。你會如何處理交易？

Question

我正在考慮使用Spring附帶的Open Session In View（OSIV）過濾器或攔截器，因為對於我作為開發人員來說，它似乎是一種方便的方式。 如果這是你推薦的，你建議使用過濾器或攔截器嗎？為什么？

我也想知道它將如何與HibernateTemplate混合，如果我將失去將方法標記為@Transactional（readOnly = true）等的能力，從而失去了獲得更細粒度的事務控制的能力？

對於如何使用Hibernate和Spring將這種解決方案與三層架構集成在一起是否有某種最佳實踐（因為我認為我決定使用Wicket進行演示應該不重要）？

如果我使用OSIV，我將至少永遠不會遇到延遲加載異常，另一方面，我的事務將更長壽，然后才能通過在視圖中未提交來提交。

Answer 1

這真的是個人品味的問題。

就個人而言，我喜歡在服務層擁有交易邊界。 如果您開始考慮SOA，那么對服務的每次調用都應該是獨立的。 如果你的視圖層必須調用2個不同的服務（我們可以說這已經是代碼味道）那么這兩個服務應該彼此獨立，可以有不同的事務配置等等......沒有事務在外面打開服務還有助於確保在服務之外不會發生任何修改。

OTOH您將不得不考慮更多關於您在服務中所做的事情（延遲加載，如果需要共同的事務性，則使用相同的服務方法對功能進行分組等等）。

一種可以幫助減少延遲加載錯誤的模式是在服務層之外使用Value Object。 服務應始終加載所需的所有數據並將其復制到VO。 您丟失了持久對象和視圖層之間的直接映射（意味着您必須編寫更多代碼），但您可能會發現您獲得了清晰度...

編輯：決定將基於權衡，所以我仍然認為這至少部分是個人品味的問題。 服務層的事務對我來說感覺更干凈（更像SOA，邏輯顯然被限制在服務層，不同的調用明顯分開，......）。 該方法的問題是LazyLoadingExceptions，可以使用VO解決。 如果VO只是持久對象的副本，那么是的，它顯然是DRY原則的一個突破。 如果您使用VO就像使用數據庫View一樣，那么VO就是對持久對象的簡化。 它仍然會有更多的代碼編寫，但它會讓你的設計更清晰。 如果您需要插入一些授權方案，它將變得特別有用：如果某些字段僅對某些角色可見，您可以將授權放在服務級別，並且永遠不會返回不應查看的數據。

Answer 2

如果我使用OSIV，我至少會遇到延遲加載異常

這不是真的，事實上它非常容易遇到臭名昭着的LazyInitializationException，只是加載一個對象，並嘗試在視圖之后讀取它的屬性，這取決於你的配置你會得到LIE