關於asp.net framework的本質

作者： -

很久沒有聊聊asp.net了，但畢竟asp.net跟我緣分不淺，或許該找個時間來談談。不過，今天我們試試看換一種方式，也讓大家自我挑戰一下，題目來囉...

  1. 我們說asp.net是一個web開發框架(framework)，現在的asp.net framework提供了三種不同的方式(途徑、架構、風格)來建立網站，分別是哪三種?
  2. 這三種分別有哪些特性(或優缺點)呢?
  3. 這三種可以混用嗎?

來公布答案。

首先，千萬別執著對錯，因為我這題目本身就很爛(題意不清)，其實我們應該把.net core和asp.net分開來看...這題談的不是asp.net core, 但題目沒說清楚，會讓人誤會。

因此，重點不是對錯，而是我們要藉著這題目來釐清整個asp.net的架構與觀念。

首先，題目與答案都在這邊:

ASP.NET is great for building standards-based websites with HTML5, CSS3, and JavaScript. ASP.NET supports three approaches for making web sites. ASP.NET Web Forms uses controls and an event-model for component-based development. ASP.NET MVC values separation of concerns and enables easier test-driven development. ASP.NET Web Pages prefers a single page model that mixes code and HTML markup. You can mix and match these techniques within one application depending on your needs - it's all One ASP.NET.

上面這段話的來源是:
https://www.asp.net/get-started/framework

所以，從這邊我們可以知道，先撇開.net core不談，asp.net framework (on windows)，主要approaches Web Sites的方法有三，分別是 WebForms, MVC, 與 Web Pages...這三者位階相同...有趣的是…Web Pages是最常被忽略的。

而另一些常見的答案諸如 Web API，SignalR ...也是asp.net框架的一部分(但不能說它主要是用來『作網站』的，嚴格說起來它們的用途是通訊)。

接著，你繼續看上面那段英文的最後一段，這三種技術，在技術上『是可以』混用的
(David註:只要你夠熟）

而特色呢？分別是:

Web Forms : uses controls and an event-model for component-based development.
MVC : separation of concerns and enables easier test-driven development.
Web Pages : a single page model that mixes code and HTML markup.

上面Web Forms和MVC的特色說得很清楚，Web Pages可能有人會覺得有點語焉不詳，但你可以從底下這邊找到更多說明:
https://www.asp.net/get-started/websites

從上面你可以知道, Web Pages有點像是過去的ASP(Active Server Pages)，提供開發人員一個最輕量級的方式來建立dynamic web content(動態網頁內容，就是從伺服器端動態抓取資訊，塞到html裡面往前端送的那種東西)，和過去ASP不同的地方是，Web Pages它主要採用了Razor View。

用比較容易理解的方式來說明:
Web Pages : 最簡單，如果IT/MIS只是要臨時開發一兩個頁面，我會推薦選擇這個方式。
Web Forms : 事件驅動、主要模擬視窗物件導向開發的控制項、具有視覺化開發、快速開發(RAD)...的特性。
MVC : 主要價值就是關注點分離(SoC)、因此也最容易實現測試驅動開發。

我自己覺得MVC對於開發人員的素質要求相對比較高，如果單就一個功能點來說，透過這個方式寫出來的Code也肯定會最多。因為SoC，因此一個功能本質上應該拆成Model/View/Controller三塊來看(來思考)，架構上相對複雜(因為比起單純的頁面多了Routing、Controller的概念)，對於初學者進入障礙就高。

而Web Forms則是開發速度快，馬上能看到結果，容易上手，但也相對最不容易開發出職責分離的架構。

Web Pages則是最直覺容易開發，但基本上沒什麼架構可言，如果頁面一多，系統一寫大基本上難以維護，但如果只是幾個頁面，那當然就非常方便好用。

就體質上來說，Web Pages 不容易寫出有職責分離、有架構、分層負責的程式碼。但Web Forms和MVC都可以(當然前提是開發人員素養夠)。Web Forms要寫出具有架構職責分離的程式碼得靠毅力(因為容易被惡魔引誘)，而MVC則是會強迫開發人員往這個方向走。

寫MVC的人如果沒能做到SoC 或 unit test/test-driven，那採用MVC的價值就大幅降低了，因為他的主要目的就是在這。而Web Forms則是為了模擬傳統的Windows 應用程式開發方式所生出來的框架，事件驅動的 event-model 和控制項是其特色，但代價就是為了去模擬狀態(State)而導致產生臃腫的ViewState。

MVC和Web Pages對於HTML Tag控制的自由度最高，而Web Forms則相對很低(特別是大量使用模擬桌面應用程式開發的Web Controls時)。

最後再順便談談 asp.net core，這個.net core，主要是為了讓系統能跨平台(例如run在Linux上)，為了這個跨平台，所有與IIS和windows平台特性的相依性都必須拿掉，這意味著過去你熟悉的system.XXX之類的namespace開始無法使用，導致.net code基本其實就是整個打掉重練，跟原本的asp.net骨子裡差異很大。

但打掉重練也就沒有包袱，可以有新的開始，但當然也意味著你過去學的不一定都能延續。至於要不要使用.net core，或是跨平台時乾脆就換一種開發技術(例如node.js)，這見仁見智，看你自己的選擇了。

所以簡單的幾個結論...

  1. 如果你想跨平台，可選用.net core(但我們今天上面那個題目，其實主要討論的不是這部分)。

  2. 如果你想寫較具有架構的網站或Web應用程式，你可以選擇 MVC 或 Web Forms，

  3. 如果只是想寫幾個頁面從伺服器端撈資料呈現給用戶，不是什麼大架構大系統，可以考慮 Web Pages。

MVC和Web Forms幾乎是不同的框架，使用目的基本上不同，也很難直接比較，但選用時其價值與核心精神(上面有討論)則必須掌握。否則若選了某一種開發方式卻沒有用到其特性，就很可惜了。

而真的有必要時，只要你夠熟悉，這三種寫法在技術上是可以混在一起用的。
(.net core則當然無法跟傳統的asp.net on windows混用)

---------------------------

以上，有沒有幫你更釐清asp.net的本質?
還是...你被搞得更暈了呢? :)

其實，不管你使用哪一種技術建立網站，只要能發揮其特性，避開缺點，凸顯其價值，並且在團隊中能夠對成員與老闆解釋的清楚，對企業來說，已經是很難得的人才了。

相關文章: http://studyhost.blogspot.tw/search/label/Framework
相關教育訓練: http://www.studyhost.tw/NewCourses/Architecture

留言

Terence Mak寫道…
很詳細的說明，謝謝你這篇文章！ :)
2017年6月30日 下午2:54
isDavid寫道…
@Terence Mak,
不客氣
2017年7月5日 上午9:48
張貼留言

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

作者： -
圖片
我好幾年沒有用傳統的關聯式資料庫了。 老實說，傳統的關聯式資料庫，其實對於教育訓練和小型的專案來說，是一種負擔。 如果你想讓學員清楚的掌握一門技術，就好比說，對談機器人的開發吧，在整個教學的過程中，若是範例用到SQL或MySQL資料庫，無疑是一種節外生枝，把問題變得更複雜。因為，在對談機器人當中，儲存只是一種迫不得已的額外需求，是枝微末節，而非對談機器人技術的主體。 同樣的，如果你做一個小型專案或POC的話，『儲存』也往往不是重點，儲存只是『必要之惡』。其實，若是從這個角度廣義的來說，軟體開發的GUI、資料庫，都只是細節(枝微末節)，都應該要是可以隨時被抽換或取代的部分，而非系統核心。 一套軟體或解決方案的真正核心，是商業邏輯。它(商業邏輯)才是一個應用程式真正展現價值的部分。 我們把主題拉回來。所以，我最近這幾年在上課的時候，盡量不讓範例程式碼涉及資料庫存取，特別是關聯式資料庫的存取。因為這對讀者或學員來說，變成了另一種必須學習的負擔。 但說的容易，如果範例中有碰到需要儲存資料的時候該怎麼辦呢? 有沒有什麼最簡單的儲存機制可以在程式碼中替代傳統資料庫? 這也是我最近幾年寫範例的時候，常常碰到的問題。因此，我特別花了一段時間，找看看有沒有什麼好用的『類』資料庫儲存體? 最後，我選擇了 Airtable。 Airtable Airtable 是一個靈活的雲端資料庫產品，結合了資料庫的功能和電子表格(data grid)的簡易性。它允許用戶以視覺化的方式存儲、組織和協作各種資訊： 白話一點說，就是它可以很自由的在Web畫面上設計欄位和維護(輸入、編輯)資料。 對我來說，它還有另一個重點，就是它擁有非常簡單的REST API，透過呼叫API就可以直接來讀寫資料。 它的API在使用上很簡單，只需要在設計好資料表之後，透過 https://airtable.com/create/tokens 站台建立一個 PAT(Personal Access Token): 建立PAT的時候，可以選擇要針對所有資料表，還是特定資料表，要只給這個token 讀取(Read)權限，還是要寫入(Write)權限： 有了token之後，可以透過很標準的REST API呼叫，進行連線的建立與資料的寫入： string ID = "👉air_tabl
Read more »

在POC或迷你專案中使用 LiteDB

作者： -
圖片
3/24，我發了篇FB 貼文 ，提到我很久沒有在撰寫範例的時候使用關聯式資料庫了。這不是因為關聯式資料庫不好，而是使用場景和情境的問題。 大部分的教學文章或範例，為求讓主題專注不要失焦，我會讓範例盡可能地簡單。例如，用Console App 取代 Web 架構，用file取代DB。這樣學員的進入障礙會再降低一點，畢竟，我們不能假設每一位學員都對MVC框架或是資料庫存取的ORM有認識。 那篇貼文得到不少迴響，其中有位讀者建議，也可以考慮用 LiteDB ，我當時回覆說我會找個時間來試試看。既然說了出口，肯定是必須要測試一下的。 LiteDB 技術上來說，LiteDB 是一個嵌入式的 NoSQL 資料庫，特別是針對 .NET 開發者設計。其本質上是一個檔案，但它提供了類似於傳統關聯式資料庫管理系統的功能，包括存儲、檢索、更新和刪除資料操作。LiteDB 以單一檔案的形式儲存在專案資料夾中，這使得它非常適合於輕量級應用。不管是desktop app、mobile app或任何需要資料庫但又不希望安裝重量級資料庫伺服器的情境，都很適合。 你只需要針對專案安裝 NuGet 套件就可以使用： dotnet add package LiteDB 不需要伺服器、不用管帳號密碼、可以跨平台，所有的資料都存儲在單一檔案，便於管理和分發、佈署。簡單的說，當我寫好範例，在裡面放一些資料，丟上GitHub，你不管在哪一個平台(Windows, Linux)，Clone下來之後，無須任何配置、設定，就可使用，資料也不會消失，無須重建。 確實，這對做範例非常方便。 你可以看看我在GitHub上的這個範例： git clone https://github.com/isdaviddong/TestLiteDB.git 下載下來之後，無須任何設定，直接 dotnet run 就可以執行： 專案中，包含了一個MyData.db檔案，就是資料庫實際儲存的位置： 你可以透過底下這樣的程式碼，即可使用： var db = new LiteDatabase ( "MyData.db" ) var col = db . GetCollection < Person > ( "persons" ) ; 其
Read more »

專業的價值...

作者： -
圖片
每次，我去修車的時候... 師傅說：先生你這車開那麼久了，這樣壞很正常拉，你要不要換台新的? 你不知道零件會老化嗎??? 我：是是是...那，這零件換掉要多少錢??? 師傅：喔...便宜啦，大概就XX萬就可以了... 每次，我去客戶那邊... 我說：大哥，這軟體我們用那麼多年了，總是會需要調整維護一下的... 客戶：是你們一開始沒有設計好吧? 我說：不是啦，技術總是會更新的，而且現在有一些新的需求...恩，大概，就收你XX萬就好了... 客戶：什麼? 你們當初沒設計好的東西，還想要加收錢??? -------------------------------------------------------------------------   我相信上面這樣的情況你一定和我一樣常碰到，我不知道有多少次，被修車廠唬的一愣一愣的，但我總是心甘情願地掏錢出來(好吧，我有點心不甘情不願，但我沒得選擇)。   有一次，我的動力方向盤打起來卡卡的，好像快不能正常轉向了，所以我立刻把車開到保養廠，師傅熱情的出來迎接我，問我車哪裡有問題，我描述狀況，接著師傅就把車開走了。剛好這時候我接到一通電話，我在講電話的同時，師傅把車弄好了(不到五分鐘)，跟我說，這個動力方向盤的油沒了，要補充，打折後收我一千多塊，我趕緊謝謝他。   離廠前，師傅把剩下的動力方向盤油給我(很有良心)，說：這是剩下的。我還沒反應過來，他就說：老闆，慢走，開車小心，注意安全。(好貼心的師傅)   我看了一下，那罐動力方向盤油只加了1/5，剩下4/5我要怎麼辦?放後車廂? 等他漏了再加? 我不知道!!! 他為何不乾脆 免費 幫我加一下呢? 像這樣類似的例子我碰過非常非常多(因為我的車老了，很多問題)   也有很多次，我明顯發現修車廠的人在唬爛我，但我換過很多家、原廠、副廠、出去玩的時候在風景區的修車廠(這更狠，擺明了就是要坑你，他清楚知道只會跟你做一次生意)，幾乎都一樣，我常常有被唬弄的感覺。我想要跟著車看他怎麼修，修車廠的師傅總是說：『老闆，您可以到休息室等一下，不會那麼快喔!!!』   對照先前我在軟體社群看到有位朋友寫的一篇 文章 ，提到了軟體工程師的無奈和心酸，我其實很想說，軟體工程師大部分真的都太古意了!!!!   從商人的角度來看，每一次免費的服務，其
Read more »

精彩(且驚人)的Semantic Kernel入門範例

作者： -
圖片
之前開直播的時候，和線上朋友聊到，因為AI的出現，未來的應用程式，勢必會和現在有所不同。 先不要跳到 黃仁勳 說的，未來『每個開發人員都可以直接用自然語言做程式設計』(這樣也太駭人聽聞了一點)，先看看眼下我們可以做到什麼程度。 你會發現透過 Semantic Kernel，這個所謂的 AI 開發框架，已經可以做到， 讓 AI 自己決定何時(以及如何)呼叫一個類別(Class)中的方法(Method) 。而我們只需要讓用戶輸入對話與機器人對談，就可以控制程式運行的流程與邏輯。也就是說，現在不需要滑鼠點選，不用選單操作，只要與機器人透過自然語言對談(底下的範例是打字，但當然可以是語音)，就可以操控系統。 我前陣子一直說的，AI 會讓 GUI 有著天翻地覆的改變，意即如此。 看底下這個類別的程式碼： //控制開關燈的類別 public class LightPlugin { //當前燈的狀態 public bool IsOn { get; set; } = false; [KernelFunction] [Description("取得燈的狀態")] public string GetState() { return IsOn ? "on" : "off"; } [KernelFunction] [Description("改變燈的狀態")] public string ChangeState(bool newState) { this.IsOn = newState; var state = GetState(); // Print the state to the console Console.WriteLine($"[Light is now {state}]"); return state; } } 上面這個很簡單的 LightPlugin 類別，具有兩個方法：GetState 和 ChangeState。這兩個方法都被標記為 [KernelFunctio
Read more »

周末讀書會 - 一如既往

作者： -
圖片
一般來說，我都是看完整本書之後，才會決定要不要推薦，能讓我還沒看完就忍不住推薦的書極少。 但『一如既往』，就是這極少中的之一。 這本書的主題很難界定，你既可以說它是在談投資、也可以說他在談經營或企管、有些內容說的是競爭、但有時候你會覺得他講的是人生。 然而重點在於，這本書寫得非常好看。 我超愛的科幻小說家倪匡，曾說過：『好看的小說非常簡單，必定要有豐富的情節、鮮活的人物，小說寫得不好看，裏面有再多的學問、道理、藝術價值，都沒有用。』 一如既往，這本書的作者厲害之處，就是他能夠把每一篇都寫得環環相扣、異常好看，然而即便我知道每篇文章的pattern，想要模仿也是很難(這是個苦功來著)。 基本上那個pattern就是…以引人入勝的故事開頭，使用對照法讓故事撐托出主題，以極具說服力的文字或數據讓主題凸顯出價值，讓讀者有所收穫，最後在最短的文字內把一篇文章總結，然後預告下一篇作者想要接著談論什麼。 就這樣，你會一篇接著一篇，不由自主的閱讀下去，每一篇，你都會有一些驚訝、會有一些省思、接著會有一些take a way。 整本書，看似信手拈來、行雲流水，一氣呵成。但我知道，這是精心設計與編排後的結果。 一本書，最要緊是好看。 好看，讓人讀得下去，裡面豐富的內容才對身為讀者的你有意義。 『一如既往』這本書做到了，而且做得很徹底。 我快看完了，看完之後，如果有時間，我還想針對裡面某幾篇特別分享，如果你等不及，不妨先找來看看。
Read more »