EventBus的思路和一些反思

本文版權歸部落格園和作者吳雙本人共同所有 轉載和爬蟲請注明原文位址 www.cnblogs.com/tdws

C#本地實作的和Redis Set實作的，實際上都是要維護一個Events和Handlers的對應關系，sub建立關系（也可以稱為Regist）, pub使用者查詢存在哪些關系，并調用。這些都是非分布式的情況，可以當你有一台應用伺服器的時候用C#字典實作對應關系的存儲就可以。當同一個應用做負載均衡于多台伺服器上，為保證釋出訂閱的對應關系，在各台伺服器上保持一緻，這個時候可使用Redis 作為一個對應關系存儲者。當然如果你確定，pub/sub關系，在程式一開始建立以後，不會被動态改變，那麼前兩者均可。

如果需要分布式處理，釋出者和訂閱者或者說生産者和消費者分離，那使用MQ和Redis的pub/sub是最合适不過的。

在将來的拓展中，隻需要定義事件對象，事件處理器和維護他們之間的關系。

也聽過這樣的說法，在項目伊始，很多設計是增加了代碼的複雜程度，應該一切從簡，以流暢開發為主。曾在一定程度上，我認為這樣的說法是有道理的，項目開始和搭建的過程中，的确要摒棄照貓畫虎的行為，不是架子漂亮就合适。但是在面對項目日益增加的需求，随之帶來的邏輯上的複雜度增加，極簡的架構的确承受不來，我見過的幾個項目存在這樣的問題，極簡的幾層=>日益龐大的邏輯層，混雜sql的邏輯，幾個甚至十幾個接口公用同一個Model。

當然這不是在抱怨，這幾個項目我也沒在寫後端的邏輯，我也不認為我一定能比誰寫得好，隻是做個反思，項目的任何問題，都是整個團隊的問題。

在過去前兩年的學習中，自己“照虎畫貓”搭架子，先建幾層接口，再用幾層實作，不管懂不懂搞個依賴注入，工廠就算面向接口了，再來個EF倉儲，工作單元，加上些遍布在代碼中到處都是的緩存這就是持久了，對了再搞個Restful風格的Api,給分頁弄個PageResult啥的等等，

想想面對複雜和日益增加的需求，終究是經不住什麼考驗，把太多的時間花在怎麼搭的漂亮，而從不考慮業務上如何抽象群組合，上面是比較主觀的一些檢討。

更讓我現在覺得不對勁的是，當初在學校 學習面向接口的時候，有些資料解釋其好處，這樣說道：“如果以後你換一個Dal層 或者你換一個service層，把這套接口重新實作一下，其他邏輯不用動。”  ， 現在想想，這說的是shit？誰會把一套service或者dal換掉？舉個恰當的栗子好嗎，讓人産生誤解影響深遠。倒不如說，你有個IRedisClient接口，提供了兩套實作，一套RedisClient和一套RedisClusterClient， 你可以在單節點和叢集間靈活切換。否則給别人一種 面向接口沒什麼意義的感覺。補充一點，從面向服務的角度，Service面向接口程式設計，是将來做RPC調用最基本的支撐，是以service需要你的IService，在服務提供者和服務消費者之間做好規範。

客觀的來看，學習的路上走彎路也算是少不了的過程，還要繼續畫下去，但更多的應該讓自己關注在解決什麼問題上，而不隻是畫的漂亮，多讀書，多實踐，不知不言，言則有據，把握本質，正确運用。

接觸過很多做C#的朋友，也有很多做Java的朋友。C#方面開發大多關注代碼層面的架構，假如他們不關注代碼層面的架構，面對日益複雜的需求，得到的結果就是嚴重耦合，難以拓展，寫到最後就是一堆面向過程的邏輯代碼，也沒有什麼出名的架構從Web層到服務，再到資料層整合的比較完善，在分布式方面的設計和解決方案還有待普及。 C#方向的童鞋研究DDD的有很多，能研究一些這樣思想的，比抱着“三層”架構寫臃腫的代碼的朋友強的多得多，至少人家有一顆将複雜業務簡單化的心。還有.net架構設計實戰此類的國産書，糾結讨論于BeginTranscation()到底能不能寫在邏輯層中，如果寫在資料層，又要摻雜了很多業務邏輯怎麼辦，難免讓人無力吐槽。

而Java方面，代碼層面的架構關注度可能少一點，在整個架構體系，從代碼層面的解耦到服務層面的解耦，拓展性方面會關注度會高一些，并且基本web項目都得益于Spring架構，各種解決方案比較完善，比如單體架構拆分成SOA。