先簡單回顧下asp.net過去十年
mvc流行前
asp.net的服務端控件，將html和js壹起封裝，很多客戶端事件自動通過生成的js將數據重新post回服務端。而對於很多剛入門的小夥伴來說，僅僅靠拖放控件和寫C#代碼就可以實現壹個可用的Web項目，大大降低了入門門檻。相應的，服務端控件這種過度耦合的設計帶來了很多缺點：自定義控制難，難以純粹將前後端分離，導致asp.net從業人員既不能精通前段技術，又不能涉獵更多的後端技術（生態問題）。
這個年代，.net被貼上了“拖放控件”的標簽。
mvc流行後
微軟推出了asp.netmvc，很多公司已經開始嘗試前後端分離。就模式上面來說，已經和其它語言平臺基於mvc的web項目開發模式無異。
但是asp.net本身的服務框架太雜亂，尤其是艱難（如果妳留意過，甚至可以說難產）支持asyncawait異步編程後，他的同步上下文模型缺點太大：首先是源碼的結構混亂，其次是使用過程很多人容易造成死鎖，異步方法使用不當導致請求已返回上下文已釋放然後找不到同步對象導致的異常。問題的根源是大部分程序員對線程了解不深，如果項目有正確的規範用法還好，壹旦沒有，產生異常很多人根本不知道問題出在哪裏。博客園改造過程中就出現過的死鎖，有興趣的可以去看看博客園官方博客寫過。
aspnetcore
新應用程序模型設計和代碼實現，我非常喜歡。其它的不說，看看那簡潔的Reqeust和Response對象，是不是就會讓妳欣喜？再看看中間件管道，上下文（Context）通過委托鏈鏈壹路傳遞，再也不用晦澀的同步上下文，也移除了和Windows安全相關的特征。
整個架構更加清晰，喜歡做擴展的人絕對會有壹日看盡長安花的快感。
自然性能也不用說，可以關註github上微軟之前做過的除了mvc之外的性能測試對比。
net生態
擁抱開源後，netcore，standard，aspnetcore，efcore等壹系列實現全部都有了，明年的netcore3.0還會包含客戶端模型（wpf和winform，只能在windows下使用）。
github上面aspnet，dotnet，dotnet-architecture等分支包含大量微軟直接維護的開源項目。
開源社區大部分的項目已經跟進將三方組件基於standard標準打包。
微軟也久違地把散亂的文檔匯集到docs子域名下
萬事劇本，就欠生態！如果apache基金會下面的重要項目都有.net的分支，相信依靠netcore必定可以再次搶占不少的份額。
前景
微服務流行後，其實內部可以混合多種平臺提供服務，用aspnetcore做對三方組件需求不太大的業務服務是完全的可以的，基於微軟壹貫的作風，開發效率是很高的。
其實現在很多內部系統在用.net，只是面向互聯網相關的項目，更加需求豐富的三方資源，采用.net的比較少。不過很多大的公司都有.net的分支團隊。畢竟在桌面和開發效率上的優勢，還是有他存在的價值。
aspnet到底會如何發展，個人感覺還是要看社區的反應，要看生態是否能逐步豐富起來。
看在微軟這麽努力的份上，個人挺希望他能夠扳回壹局。
所以？
眼光放長遠壹點，平臺只是我們的工具，壹個IT人不應當把自己的技術範圍限定到某壹個平臺。多學多積累，實際項目中應該針對需求、架構以及團隊做出選擇。
比如Java和.net同時掌握，各取所長，基於他們重疊性較高的原因，學習成本並不高。何況絕大部分的知識和平臺並無關系。
個人見解純手打，歡迎大家評論或者提出意見。