想問題一下我開始深入接觸時就是MVC設計模式
但裏面其實也沒有用到C#物件導向設計方式，反而比較像進階版的WebForm
而WebForm我是沒有深入研究，有大約玩過，感覺像以前Visual Basic Windows Forms, 只是改成網頁方式，但因為介面太強所以程式上的處理只要專心在控制表單元件
但後來發現像MVC WebAPI這些純寫程式，雖然MVC也有views, 但那views的基本是不能拿來和有一位專業設計師來比，而程式設計感覺好像就能用到物件導向設計方式
比較能發揮c#程式的極限，是這樣嗎
還有微軟除了webapi，目前怎麼看前端的views看來都還是得後端程式人員來套，而沒有辦法讓前後端分離
已邀請的邦友 {{ invite_list.length }}/5
Asp.net MVC 跟 Asp.net webForm 本質上架構就不一樣，
至於你說的view應該是指UI吧，基本上html能做的上面都能做，
漂不漂亮純粹是製作者的緣故，
至於C#物件導向，只要是C#都可以用跟framework無關
有spa網站，就可以各做各的
相關連結: https://docs.microsoft.com/zh-tw/aspnet/core/client-side/spa/angular?view=aspnetcore-6.0&tabs=visual-studio
雖然我不清楚你的前後端職責分離定義
設計UI、前端工程師、後端工程師像這樣嗎?
如果只想碰C#，那Web API確實最適合你，
但部分一條龍居多...
我覺得你對前後端分離和MVC模式（我知道有些人會說目前全端框架這不是MVC，但這不是我的重點）有些誤解。
所以你如果要當個專注於後端的開發者，那你只要跟前端商量好api，並且去實踐他。
但後端是不是就此輕鬆？你還有架構的優化、資料庫優化、路由的設定、資安議題等更深刻的問題在等你。
也就是只要你用的工具能提供web api給前端自己用js和html自給自足，不用你幫他填template，不管是純php、asp還是webform、MVC、core，都可以是前後端分離。
只是看你專案及資源大小適不適合這種開發模式罷了。
像我就只開發中小型的企業內部網站並且是個全端，除非想要很注意UX，我不會去搞前後端分離。小專案就更不可能了。
從開發人員角度可以職責分工明確
從老闆眼中沒辦法凹一個工程師前後端一條龍全包
而且還要找額外雇一個前端工程師或者視覺、美編、設計(純layout html畫面或用dreamweaver)
所以可能還要有辦法說服老闆為何要走前後端分離(當然你只用技術層面去講可能行不通)
因為對於不是很重視軟體的產業而言
只在乎有捨麼效益、 看起來要多花錢...
可能可從成本面可以節省多少去說服
舉例
1.比方若未來擴展到手機也要寫應用重複的程式功能無法抽離
可能要多花錢雇專精APP開發的工程師然而走前後端後可把共用邏輯抽離去導入
就算是只會web的工程師只要APP有需要開發的功能面不需要太複雜其實只要鑽研api存取的部分即可
2.比方可能是產線很多機台工作站的電腦(假設可能Windows)
每一台都要買微軟的授權若有500台成本十分可觀(若都走vb.net,C# winform或其他的程式比方java)，因此應走向web來控管。
1.目前的程式設計師,真正使用物件導向設計方式的人不到1%.很多以為在用物件導向方式寫程式的其實都不是物件導向
2.MVC與WebForm機制上完全不同,不需要比較
3.目前使用ASP.Net MVC的99%都不是用真的MVC模式在寫,而是把MVC當作Webapi在用,大部分的書籍跟文章也是如此.
1.對，我後來看了一堆物件導向設計，原本我以為HttpContext.Current.Request點來點去就叫物件導向，但後來發現完全不是這樣，而且中小案子或是說沒有事前規畫確定分功誰要做什麼，你要做什麼然後讓我用，才比較有可能用到物件導向
3.真的我看到的就是return Content("OK");前端jQuery去叫mvc controllers，成功就ok 只是mvc比較好笑是，前端網頁雖然是設計師幫你做好美美的版，但還是要交給你，你要自已分配切看要怎麼放在views，然後還要自已寫jQuery POST自已的controllers
但若是webapi，前端就完全是要由前端去處理，後端完全不會去碰到，但前提是要請的到一位有美工又有javascript jQuery的神工，這個種人材應該很難找
webform 當時的目標情境其中應該有一個是為了讓 winform 開發者快速銜接, 至於是否用物件導向開發是沒有直接關係的.
我覺得二種都有自己的特色，例如，你只有一個人做的話，像全端，還要搞前面的美工，到後面的資料庫等等，如時間不夠，當然是用WebForm較快，如果你的專案有很多人，使用MVC來開發較快速，合作也較方便，所以二種各有特色，一樣可以達到目標就看你怎麼想而已
不論是你是系統設計或程式開發的工作,物件導向/程序導向是各有利弊的
限於系統開發時人力/時間成本+需求+未來變異度,必需與現實妥協,上線時沒有完美的系統
只有上線後可及時修正穩定的系統(有已知代修正的BUG)
物件導向 : 程式難寫且執行效率較低,小系統開發成本太高,大系統架構品精簡容易維護
程序導向 : 程式單純好寫且執行效率較易控制,小系統開發成本合宜,大系統程式龐大不容易維護
但當系統變大時,會增加常用的物件以取代原程式
例如 : 一個申請簽核系統中10~25%會是用物件導向完成的,50~65%是程序導向完成的
而此系統使用5年後,可能又有10~20% 物件導向會取代程序導向,於重構程式後 增加常用的物件以取代原程式
若ASP.NET WebForm是木器時代 , ASP.NET MVC 是鐵器時代
不論時代為何都是可以加減系統中 物件導向/程序導向 比例
現代而言 原料成本 鐵器==木器 , 1000年前 鐵器>>木器
同理 當電腦硬體越來越強大時 , ASP.NET MVC/程序導向 使用比例會變多
iThome鐵人賽
看影片追技術