David Fowler ：actor框架為什麼沒能流行起來？

banq發表於2019-10-31
框架

眾說紛紜：
如果您正在尋找更好的方法，並且已經找到了CQRS/ES，那麼它們是多餘的。

如果actor用作聚合或事件投射，可以很好地與CQRS/ES一起工作，我過去曾在奧爾良做過。

因為這與人們被教導為Web應用程式的好東西（無狀態計算）的模型相反？如果一個人的背景全是關於將狀態問題推送到資料庫的，那麼可能很難理解Actor為什麼有用。

抽象得過於複雜。構建一次性或一次性應用程式並不容易。這需要大量的學習投入。

我正在使用Actor系統。血腥的很難除錯。為什麼狀態更改發生或沒有發生。為什麼一條訊息從未得到答覆。DI不能很好地工作。特別是對於MS DI或EF。由於沒有作用域（我們將作用域定義為訊息），因此必須為EF進行復雜的操作。

大多數應用都是CRUD。人們編寫應用程式將資料扔到資料庫中，並讓它照顧併發性（無論是天真還是樂觀）

而且仍然大多數人會弄錯它並導致資料不一致。我都程式碼邏輯推理沒有問題，但還是不確定，不如將資料扔到資料庫中並假定它將解決所有併發問題。

在我的經驗（非常有限）中：它除錯困難，可組合性有限

因為雲原生工具贏了。雲產品中存在建立群集，服務發現，pub sub，監視，PaaS託管等功能。Actor框架中存在零退出策略。

難以引導（前期設計成本高，而“我將開始在此Web應用程式中丟擲端點”要簡單得多）和除錯困難是兩個主要原因。

如果在水平擴充套件時建立狀態服務，則會變得非常複雜。

在大約4年使用.NET（fw和Core）中的actor框架構建各種應用程式後，我的個人感覺是：由於缺少呼叫棧，並且僅透過呼叫固有的清晰介面/型別安全性，很難除錯應用程式傳送訊息。

與傳統應用程式（DDD，洋蔥架構）相比，其優勢尚不清楚。難以推斷整個系統狀態。強制執行特定的程式設計方式。模型並非每個人都喜歡或適合。想想如何將所有現有領域模型重構到一組Actors？

強烈推薦 http://nact.io

這是程式設計思考的正規化轉變。以我的經驗，大多數人對OOP並不完全精通，因此正規化轉換會帶來額外的提升。

定義一個類專門來傳送資料，這有點設計過頭，這是一種思考問題的方法，這是大多數人不習慣的另一種方式。但是，如果您的解決方案很複雜並且需要可伸縮性，那就太好了。

我們不需要Actor帶來的額外框架複雜性。我認為，只有在複雜性和併發性達到一定程度時，它們才能帶來收益，而收益要超過模型的成本。在90％的情況下，crud很好。

actor的組合不及函式。如果將事情解耦得太多，則可能會失去型別安全性的許多好處。




















 

相關文章