有幾種不同的方法,您使用哪種方法取決於多個因素,包括業務流程的複雜性,所需的靈活性和負載的程度。
簡單的解決方案
- 「RSVP更新」 直接寫入期間 「RSVP」 過程中的一些數據源;這個過程本質上是硬編碼的。
- 有些東西直接從它們所在的數據源/表中讀出RSVP。
- 如果負載和數據量過大,此解決方案將會正常工作。關鍵在於RSVP UI小部件最終將數據從與寫入更新的位置相同的數據源中提取出來。
性能
幾個不同的選項,基於上述作爲起始點:
- 握住數據兩次:RSVP的一次中的「主」(事務)表數據,並且一次在用於爲UI服務的表格中(基本上OLTP vs OLAP)。第二個表格將包含所有相關數據,以便沒有其他表格的查找,並且由於它是數據的獨立副本,所以您可以按不同方式對其進行管理(例如:清除舊記錄以便表格大小保持很小)。
- 或者,而不是第二個表,只是將所有的數據保存在內存中。這將需要您在內存副本丟失時將數據從主事務表中提取出來。
靈活性
- 原來一樣的方法,但是代替硬編碼在記錄了該RSVP(成單個數據源)的步驟使用更鬆耦合的方法,使你可以添加/更改/刪除儘可能多的事件處理器。一個會將RSVP數據寫入主RSVP數據源,而另一個將執行相同/相似的操作,但是已經爲「最近的RSVPs」UI Widget準備好了。
- 依賴注入將爲您提供靈活性 - 當然,如果您處理事件處理程序的單個實現。
- 發佈/訂閱或責任鏈patterns可能會爲您提供一種方法的基礎。
這是你之後的那種信息嗎?