David Fowler :actor框架為什么沒能流行起來?

19-10-31 banq
                   

眾說紛紜:

如果您正在尋找更好的方法,并且已經找到了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的組合不及函數。如果將事情解耦得太多,則可能會失去類型安全性的許多好處。

?

                   

3
美女漫画大全