在本書的第一部分，我們將簡要介紹C#語言，並討論它的一些特性。第1章介紹了什麼是C#和.NET，以及為什麼您會（也不會）在專案中使用它們。第2章深入探討了.NET的各種迭代，並在編譯過程中採用了C#方法，在編譯過程的每一個主要步驟都停止下來 。

儘管這部分確實是本書的介紹，但它仍然為熟悉C#的人提供了寶貴的資訊。前兩章中介紹的一些知識是您在繼續學習更高階主題之前需要了解的。

第1章 C#和.NET簡介

本章包括

• 瞭解C#和.NET是什麼
• 瞭解為什麼要在專案中使用C#（以及為什麼不使用）
• 切換到C#以及如何開始

你說是另一本關於C#的書嗎？是的，另一個。很多書都是關於C#和.NET的，但這本書有一個根本的區別：我寫這本書是為了幫助您在日常生活中開發乾淨、地道的C#程式碼。這本書不是一本參考書，而是一本實用指南。本書不涉及如何編寫if語句、方法簽名是什麼或物件是什麼之類的內容。我們不關心語法，而是關注概念和想法。瞭解語言的語法和能夠編寫乾淨、地道的程式碼是有區別的。讀完這本書後，這正是你能夠做到的。無論你的背景是什麼，你知道什麼程式語言，只要你瞭解面向物件程式設計，這本書將幫助你轉向C#和.NET生態系統，如圖1.1所示。

 圖1.1每一章的介紹都包含一個進度圖，可以讓您快速瞭解自己在書中的位置。

 微軟、谷歌和美國政府等組織有什麼共同點？他們都使用C#，這是有充分理由的。但為什麼？C#只是另一種程式語言。它與Java和C++有相似之處，支援面向物件和函數語言程式設計，並得到了大型開源社群的廣泛支援。太棒了現在，你為什麼要在意？在本章中，我們將深入探討這個問題，但讓我透露一些劇透：C#擅長於允許您建立可擴充套件軟體。要開始編寫C#，您所需要的只是自己選擇的.NET SDK（第2章將詳細介紹），也許還有一個IDE。語言和執行時是開源的。

每當你在網上尋找C#時，很可能會遇到.NET框架。您可以將.NET Framework視為冬日的溫暖毯子、溫暖的爐火和一杯熱巧克力，為您提供所需的一切：封裝低階Windows API的庫、公開常用的資料結構以及為複雜演算法提供包裝器。C#中的日常開發幾乎肯定涉及到.NET Framework、.NET Core或.NET 5，因此我們將在適當的時候探討這些框架。

圖1.2顯示了本書主題在通用.NET Web架構中的適用範圍。它還顯示了我們用來完全重寫現有應用程式的架構，我們將從第5章開始（綠色/虛線箭頭指示此路徑）。

 圖1.2 Microsoft stack上的典型web服務架構示例。本書遵循綠色/虛線箭頭所示的方法。本書涵蓋了演示、業務邏輯和資料訪問層。

對於那些有過C#經驗的人：本書介於初學者和高階資源之間。通過本書中所教的技能，您可以彌補知識差距，併為高階技能做好準備。前兩章對你來說可能有點基礎，但我請你不要跳過這些。重新整理你的知識總是很好的。

1.1 為什麼使用C#？

如果您已經熟悉C#以外的程式語言並喜歡使用它，為什麼要使用C#？也許你受僱於一家只使用C#的公司。或者你只是想看看這一切都是為了什麼。

我保證不會重複告訴你，C#是一種“支援跨平臺開發可擴充套件企業軟體的強型別面向物件程式語言”。在本節中，我們只介紹了定義中的流行詞，不再贅述。儘管聽起來我是微軟營銷部門的員工，但在本節的其餘部分，我們將重點關注以下C#的亮點和用例：

• C#（以及.NET生態系統）以經濟的方式支援軟體開發。經濟的解決方案很重要，因為企業開發是C#的麵包和黃油。
• C#可以提高程式碼的穩定性和可維護性，因為它支援自記錄程式碼、安全庫和易用性。
• C#對開發人員友好，易於使用。沒有什麼比發現你想要使用的程式語言沒有很好的支援你喜歡的東西（例如穩定的包管理器、對單元測試的良好支援以及跨平臺執行時）更糟糕的了。

當然，編寫可擴充套件、可維護和開發人員友好的“乾淨程式碼”可以用大多數（如果不是所有）程式語言完成。不同之處在於開發人員的經驗。有些語言非常擅長指導您編寫乾淨的程式碼，而其他語言則不然。C#並不完美，但它確實試圖在這方面幫助您。

1.1.1 原因1：C#很經濟

C# 使用和開發是完全免費的。語言和平臺是完全開源的，所有文件都是免費的，大多數工具都有免費的選項。例如，常見的C#安裝程式包括安裝C#8、.NET 5和Visual Studio社群。所有這些都是免費的，並在本書中使用。執行時不需要許可費，您可以在任何地方部署最終產品。

1.1.2 原因2：C#可維護

當我們在本書中談到可維護性時，我們指的是修復bug、更改功能和解決其他問題而不會產生意外副作用的能力。這聽起來像是任何程式語言的明顯要求，但很難實現。C#具有提高大型程式碼庫的可維護性（因此，安全可擴充套件性）的特性。例如，考慮泛型和語言整合查詢（LINQ）。我們將在整本書中討論這兩件事，但它們是平臺的一個例子，揭示了可以幫助您編寫更好程式碼的功能。

對於一家公司來說，可維護性可能不是表面上的第一要務，但如果您開發的程式碼是可維護的（意味著乾淨的程式碼易於擴充套件並有測試支援），開發成本就會降低。在編寫可維護程式碼時降低開發成本最初看起來可能違反直覺：可維護程式碼需要更長的時間來編寫和構建，從而提高了開發的初始成本。然而，想象一下當用戶發現一個bug或者他們想要一個額外的功能時，一段時間後會發生什麼。如果我們編寫了可維護的程式碼，我們可以快速輕鬆地找到錯誤（並修復它）。新增該特性更簡單，因為程式碼庫是可擴充套件的。如果我們可以輕鬆地擴充套件和修復程式碼庫，開發成本就會降低。

開啟/關閉原則
1988年，法國電腦科學家貝特朗·邁耶（Eiffel程式明語言的創造者）出版了一本名為《面向物件的軟體構造》（Prentice Hall，1988）的書。邁耶的書的釋出是面向物件程式設計和設計史上的一個關鍵時刻，因為在書中，他引入了開放/封閉原則（OCP）。OCP旨在提高軟體設計的可維護性和靈活性。Meyer表示，OCP意味著“軟體實體（類、模組、函式等）應開放進行擴充套件，但關閉進行修改。”
但OCP在實際意義上意味著什麼？為了檢驗這一點，讓我們將OCP應用於一個類：如果我們可以在不改變現有功能的情況下向類新增功能（因此，可能會破壞部分程式碼），那麼我們認為一個類“開放”用於擴充套件，“封閉”用於修改。如果您遵守這一規則，那麼在現有程式碼中引入迴歸（或新bug）的可能性要比在不考慮可維護性和可擴充套件性的情況下強行引入bug修復或新特性的可能性小得多。當您使用更復雜的程式碼時（並且是耦合的；在第8章中討論過），您更可能由於錯誤理解更改的副作用而引入新的bug。這是我們不惜一切代價想要避免的。

1.1.3 原因3：C#對開發人員友好且易於使用

企業開發是C#開發的麵包和黃油，也是C#和.NET的亮點所在。在企業環境中，理想的程式碼庫是什麼樣子的？也許你想要一個程式碼庫，它可以很容易地用一個可靠的軟體包管理器進行導航，並有測試（單元、整合和煙霧）支援。讓我們還提供優秀的文件和跨平臺支援。

定義：自記錄程式碼意味著程式碼寫得足夠清楚，我們不需要註釋來解釋邏輯。程式碼文件本身。例如，如果您有一個名為DownloadDocument的方法，其他人可以對它的作用有所瞭解。無需添加註釋，說明方法內部的邏輯。

最重要的是，也許我們可以與雲服務進行良好的整合，以實現持續整合和交付（CI/CD）。一個務實的觀點告訴我們，你擁有這樣一個程式碼庫的可能性不是很高。當然，這個願望清單對於大多數情況來說都是不切實際的。然而，如果你想做其中的一些事情（如果你喜歡冒險的話，也可以全部做），C#不會對你不利。它提供了現有的工作流程、功能和本機庫，可以讓您實現99%的工作效率。

來自Java等語言的開發人員應該在專案結構中看到一些相似之處。雖然存在一些差異，但它們並不大。我們將在全書中深入討論C#專案結構。

.NET還支援幾種流行的測試框架。Microsoft提供了Visual Studio單元測試框架，它包含（有時也被稱為）MSTest。MSTest只是Visual Studio單元測試框架的命令列執行程式。其他常用的測試框架是xUnit和NUnit。您還可以找到Moq（Moq類似於Java的Mokito或Go的GoMock。我們將在10.3.3節中瞭解更多關於將Moq與單元測試一起使用的資訊）、SpecFlow（類似於Cucumber的行為驅動開發）、NFluent（一個流暢的斷言庫）、FitNesse等等。

最後，您可以在許多平臺上執行C#，儘管有一些限制（一些較舊的平臺僅限於較舊版本的C#和.NETFramework）。使用.NET 5，您可以在Windows 10、Linux和macOS上執行相同的程式碼。這個功能最初是.NET Core，它是.NET Framework的衍生產品，後來與.NET Framework（以及其他框架）合併建立了.NET 5。您甚至可以通過Xamarin在iOS和Android上執行C#程式碼，也可以通過Mono在PlayStation、Xbox和Nintendo Switch平臺上執行C#。

1.2 為什麼不在C#中工作？

在任何情況下，C#都不是每個人的最佳選擇。你必須為這份工作選擇最好的工具。C#在各種情況下都能很好地工作，但在以下幾種情況下，您可能不希望使用C#和.NET：

• 作業系統開發
• 實時作業系統驅動程式碼（嵌入式開發）
• 數值計算

讓我們簡要分析一下為什麼C#可能不適合這些用例。

1.2.1 作業系統開發

作業系統（OS）開發是軟體工程的一個極其重要的角落，但開發OS的人並不多。開發一個作業系統需要花費大量時間和精力，程式碼庫通常會進入數百萬行程式碼，經過多年甚至幾十年的開發和維護。

C#不適合作業系統開發的主要原因歸結為對手動記憶體管理（非託管程式碼）和C#編譯過程的支援參差不齊。雖然C#允許在使用“不安全”模式時使用指標，但在記憶體管理的易用性方面，它不能與C這樣的程式語言相媲美。

使用C#開發作業系統的另一個問題是它部分依賴於實時（JIT）編譯器（第2章將對此進行詳細介紹）。想象一下，必須通過虛擬機器執行作業系統。效能將是一個問題，因為虛擬機器必須一直進行追趕以執行JIT編譯的程式碼，這與在計算機上執行.NET程式碼時發生的情況類似。這種批評意味著完全靜態編譯的語言更適合作業系統開發。

然而，用高階語言開發的作業系統的例子確實存在。例如，Pilot OS（由Xerox PARC於1977年建立）是用Java的前身Mesa編寫的。

如果您想了解有關作業系統開發的更多資訊，請訪問osdev的wiki。org社群是一個極好的資源（wiki.osdev.org）。在那裡，您可以找到入門指南、教程和閱讀建議。學習C的資源包括Jens Gustedt的《Modern C》（Manning，2019）和Brian Kernighan和Dennis Ritchie的經典著作《The C Programming Language》（Prentice Hall，1988）。

1.2.2 C#中的實時作業系統嵌入式開發

與作業系統開發（第1.2.1節）類似，實時作業系統（RTOS）驅動的程式碼（在嵌入式系統中最常見）在通過虛擬機器執行時會遇到很大的效能問題。RTOS實時線性掃描程式碼，並以可配置的間隔執行指令，該間隔範圍從每秒一次操作到每微秒多次操作，這取決於開發人員的意願和程式碼執行的微控制器或可程式設計邏輯控制器（PLC）的能力。由於增加了執行時的延遲和開銷，虛擬機器阻礙了真正的實時執行。

如果你想了解更多有關RTOS驅動的程式碼和嵌入式開發的資訊，你可以看看幾本備受推崇的書，比如David E.Simon的《An Embedded Software Primer》（Addison Wesley Professional，1999），或者Elecia White的《Making Embedded Systems: Design Patterns for Great Software》（O'Reilly Media，2011）。

1.2.3 數值計算和C#

數值計算（也稱為數值分析）涉及演算法的研究、開發和分析。從事數值計算的人（通常是電腦科學家或數學家）使用數值近似來解決幾乎所有科學和工程分支中的問題。從程式語言的角度來看，它提出了獨特的挑戰和考慮。每種程式語言都可以計算數學語句和公式，但有些語言是專門為此目的而構建的。

考慮繪製圖形。C#絕對可以處理繪圖，但與MATLAB相比，C#提供了什麼效能和易用性？（MATLAB既是一種計算環境，也是MathWorks建立的程式語言。）簡單的答案是，它無法進行比較。C#中的圖形程式設計可以讓您在WPF（使用Direct3D）、OpenGL、DirectX或其他第三方圖形庫（通常針對視訊遊戲）中工作。有了MATLAB，你就有了一種與渲染複雜三維圖形的環境相聯絡的語言。您可以直接呼叫plot（x，y），MATLAB為您繪製圖形。

因此，C#可以進行數值計算，但不能像MATLAB那樣提供與高階庫和抽象處理圖形繪製的語言相同的易用性。如果您有興趣瞭解更多有關MATLAB或數值計算的資訊，這些主題的一些可用資源包括Richard Hamming的《Numerical Methods for Scientists and Engineers》（Dover Publications，1987）、Amos Gilat的《MATLAB: An Introduction with Applications》（Wiley，2016）以及MATLAB的Cody教程程式(https://www.mathworks.com/matlabcentral/cody)。

1.3 切換到C#

由於語言之間的相似性，對Java虛擬機器（JVM）語言（最著名的是Java、Scala和Kotlin）或C++的語法有很好理解的開發人員可能會比來自非C風格語言、非虛擬機器風格語言或以web和云為中心的語言（如Dart、Ruby或Go）的開發人員更容易閱讀本書。來自非C風格語言背景並不意味著C#不可能被理解。你可能會發現自己重讀了一些段落兩遍，但最後，你會很好地讀到。

如果您來自一種解釋語言（如Python），則.NET編譯過程最初可能看起來很奇怪。.NET範圍內的語言使用兩步編譯過程。首先，程式碼被靜態編譯為一種稱為公共中間語言（Common Intermediate language，簡稱CIL、IL或MSIL；MS for Microsoft，對於我們中的Java開發人員來說，它有點類似於Java位元組碼）的低階語言，而當.NET執行時在主機上執行程式碼時，它又將即時（JIT）編譯為本機程式碼。所有這些聽起來可能很難突然消化，但在幾章之後，你就會明白了。

如果您來自諸如JavaScript之類的指令碼語言，靜態型別可能會限制您並使您感到沮喪。但一旦你習慣了知道自己的型別，我想你會喜歡的。

如果你來自Go或Dart這樣的語言，在那裡有時很難找到本地庫，.NET 5可能會以其豐富的庫庫讓你大吃一驚。通過為您能想到的大多數內容提供函式，.NET庫是您的主要功能源。許多用.NET編寫的應用程式從不使用任何第三方庫。

為了避免內務管理，讓我們討論一下工具。在本章中，我們將不深入探討如何安裝IDE或.NETSDK。如果您尚未安裝.NET SDK或IDE，並且需要幫助，可以在附錄C中找到一些快速安裝指南。要繼續閱讀本書，您需要安裝最新版本的.NET Framework和.NET 5。在本書中，我們將從使用.NET Framework的舊程式碼庫開始。因此，當我們將程式碼遷移到.NET5時，我們將使用.NETFramework執行舊程式碼庫。

如前所述，C#是開源的，由社群在Microsoft的幫助下維護。您不需要為執行時、SDK或IDE許可證付費。關於IDE，Visual Studio（我們將在本書的示例中使用的IDE）有一個免費的社群版，您可以使用它來開發個人專案和開源軟體。如果你喜歡你當前的IDE，你很可能會找到一個C#外掛。您還可以使用命令列來編譯、執行和測試C#專案，儘管我鼓勵您給專用的C#工具（Visual Studio）一個機會，因為它提供了編寫慣用C#程式碼的最流暢的體驗和最簡單的途徑。

您在其他地方學到的許多概念和技術都轉移到了C#，但有些沒有。C#在後端比在前端更成熟，因為它傳統上主要用於這一目的。歷史上對C#後端開發的關注並不意味著前端體驗就不那麼令人印象深刻。您可以用C#編寫一個完整的stack應用程式，而無需接觸JavaScript。雖然本書側重於後端開發，但這裡教給您的許多概念也能幫助您實現前端開發。

你有沒有遇到過一個包含五個巢狀for迴圈、一堆硬編碼數字（所謂的魔術數字）和比程式碼更多註釋的怪物方法？假設你是一個剛加入團隊的新開發人員。當您啟動IDE、下拉原始碼並看到此方法時，您會有什麼感覺？絕望無法完全掩蓋。現在想象一下，您將怪物方法中的所有單獨操作都放在它們自己的小方法中（可能少於5到10行程式碼）。你的怪物方法是什麼樣子的？程式碼不像是一堆難以理解的條件和任務，除非你有特定的領域知識，否則沒有清晰的理解路徑，程式碼讀起來就像是一個故事。如果你能很好地說出你的方法，你的主要方法應該讀起來像一個食譜，即使是最糟糕的廚師也能遵循。

當我提到“乾淨的程式碼”時，我指的是羅伯特·C·馬丁在他的視訊中宣揚的編碼實踐(https://cleancoders.com/videos)以及《清潔程式碼》（Prentice Hall，2008）、《Clean Code》（Preantice Hall）（2017），以及與Micah Martin合著的《Agile Principles, Patterns, and Practices in C#》（Pearson，2006），以及通過他對“SOLID”原則（單一責任原則、開放/封閉原則、Liskov替代原則、介面隔離原則和依賴反轉原則）的彙編。我在書中詳細解釋了乾淨程式碼原則，以及如何實際使用它們的實用資訊。

說到底，為什麼要編寫乾淨的程式碼呢？乾淨的程式碼就像洗衣機一樣處理錯誤和不正確的功能。如果我們將程式碼庫放在乾淨的程式碼清洗機中，如圖1.3所示，我們會看到，一旦您重構一些東西以使其更“乾淨”，就會出現錯誤，錯誤的功能會無處藏身。畢竟，“一切都是水落石出”。當然，重構生產程式碼也是有風險的；通常會產生意想不到的副作用。這使得管理層很難批准沒有附加功能的大型重構。然而，使用正確的工具（本書中討論了其中一些工具），您可以最大限度地減少負面副作用的機會，並提高程式碼庫的質量。

 圖1.3 乾淨的程式碼就像一臺洗衣機。它將你的髒衣服（你的程式碼），加入肥皂和水（清潔程式碼原則），並從衣服上分離汙垢（從程式碼中分離bug）。它留給你的是衣服（程式碼），汙垢（bug）比你開始時少。

這本書包含了關於乾淨程式碼主題的資訊。如果邊欄與乾淨的程式碼相關，我將它們表示為這樣，並解釋這兩個概念以及如何將它們應用於現實世界。附錄B包含一份清潔程式碼清單。您可以使用檢查表來確定是否需要重構現有程式碼。清單提醒了一些更容易忘記（但仍然重要）的概念。

1.4 你將在本書中學到什麼

本書將教您編寫地道而乾淨的C#程式碼。它不從頭開始教C#語言、.NET 5或程式設計。我們遵循一種實用的方法：一種業務場景，在該場景中，我們重構舊的API以使其更加乾淨和安全。一路上，你會學到很多東西。以下是一些亮點：

• 採用舊程式碼庫並對其進行重構，以提高安全性、效能和清潔度
• 編寫可通過任何程式碼審查的自記錄程式碼
• 使用測試驅動開發與實現程式碼一起編寫單元測試
• 通過實體框架核心安全連線到雲資料庫
• 將乾淨程式碼原則引入現有程式碼庫
• 閱讀通用中間語言並解釋C#編譯過程

那麼，你需要知道什麼才能充分利用這本書？期望您瞭解面向物件程式設計的基本原理（繼承、封裝、抽象和多型性），並熟悉另一種支援通過面向物件方法開發程式碼的程式語言（無論是C++、Go、Python還是Java）。

閱讀本書後，您將編寫乾淨、安全、可測試的C#程式碼，這些程式碼遵循良好的面向物件設計原則。此外，您將準備通過高階資源進一步加深您的C#知識。本書之後的一些建議讀物包括喬恩·斯凱特的《C# in Depth》，第4版（曼寧，2019），傑弗裡·裡希特的《CLR via C#》，第四版（微軟出版社，2012），比爾·瓦格納的《Effective C#》第二版（微軟社，2016），達斯汀·梅茨加的《.NET Core in Action》（曼寧出版社，2018），約翰·史密斯的《Entity Framework Core in Action》，第二版，Andrew Lock的《ASP.NET Core in Action》，第二版（Manning，2021）。

1.5 本書中你不會學到的東西

本書旨在填補初學者和高階C#資源之間的空白。有了這個目標，我對你對C#和程式設計的理解做出了什麼樣的假設。正如這裡簡要討論的那樣，我希望您有一些專業的程式設計經驗，並且您熟悉C#的基礎知識或不同的面向物件程式語言。

 我這是什麼意思？為了充分利用這本書，您應該瞭解面向物件的原則，並能夠用您喜愛的程式語言開發基本應用程式或API。因此，本書沒有教給您初學者程式設計書中經常出現的以下主題：

• C#語言本身。這不是一本遵循《從頭開始的C#程式碼》的書。相反，我教你如何將現有的C#或面向物件程式設計知識提升到下一個層次。
• 圍繞不特定於C#的條件語句和分支語句的語法（if、for、foreach、while、do while等）。
• 什麼是多型性、封裝和繼承（儘管我們在本書中經常使用這些概念）。
• 什麼是類以及我們如何通過類來建模真實世界的物件。
• 什麼是變數，或者如何為變數賦值。

如果你是程式設計新手，我強烈建議在閱讀這本書之前，先閱讀一本書，比如詹妮弗·格林的《Head First C#》，第4版（O'Reilly，2020）或哈羅德·阿貝爾森（Harold Abelson）、傑拉爾德·傑伊·蘇斯曼（Gerald Jay Sussman）和朱莉·蘇斯曼（Julie Sussman，《Structure and Interpretation of Computer Programs》，第2版（麻省理工學院出版社，1996）。

本書也沒有介紹這些更專門的C#使用方法：

• 微服務架構。本書沒有深入探討微服務是什麼以及如何使用它們。微服務架構在很大程度上是一種趨勢，在許多用例中都很有用，但與C#或您如何像專業人員那樣編寫程式碼無關。瞭解更多關於微服務的三個精彩資源是Chris Richardson的《Microservices Patterns 》（Manning，2018）、Prabath Siriwardena和Nuwan Dias的《Microservices Security in Action》（Manning，2019）以及Christian Horsdal Gammelgaard的《Microservices in .NET Core》（Manning）。
• 如何在Kubernetes和/或Docker等容器化環境中使用C#。雖然非常實用，並且在許多企業開發環境中使用，但知道如何使用Kubernetes或Docker並不能保證您可以在C#中“像專業人員一樣編寫程式碼”。要了解更多有關這些技術的資訊，請參閱Marko Lukša的《Kubernetes in Action》第二版（Manning，2021）、Elton Stoneman的《learn Docker in a Month of Lunches》（Manning）（2020年）和Ashley Davis的《Bootstrap-ping Microservices with Docker，Kubernete，and Terraform》（2021）。
• 除了多執行緒和鎖之外，與C#的併發性（在第6章中討論）。我們經常在高度執行緒化和效能關鍵的場景中發現這個主題。大多數開發人員不怎麼使用這樣的程式碼。如果你確實發現自己處於這個位置，那麼瞭解更多關於C#併發程式設計的絕佳資源是喬·達菲的《Concurrent Programming on Windows 》（Addison Wesley，2008）。
• CLR或.NETFramework本身的深層內部細節。儘管CLR和.NET5很有趣，但瞭解它們的每一個細節對大多數開發人員來說都沒有什麼實際用處。本書涵蓋CLR和。NET框架，但當事情變得不切實際或笨拙時就停止了。CLR和.NET框架的“聖經”是Jeffrey Richter《CLR via C#》第4版（微軟出版社，2012年）。

你有兩種方法讀這本書。推薦的方法是從頭到尾按順序閱讀整本書。如果您只對重構和最佳實踐感興趣，可以閱讀第3部分至第6部分。

總結

• 本書不涉及“程式設計101”，它假定了面向物件程式設計的知識。這使我們能夠專注於實際概念。
• C#和.NET 5在可擴充套件的企業開發方面表現出色，注重穩定性和可維護性。這使得C#和.NET成為公司和個人開發人員的理想平臺。
• C#和.NET5在作業系統開發、RTOS嵌入式開發或數值計算（或分析）方面並不出色。對於這些任務，C和MATLAB更適合。