Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

在本系列文會利用目前 Visual Studio 內建的專案樣本建立一個初始的 .NET MAUI 專案，並且透過此 .NET MAUI 專案來把 TopStore App 的開發從 Xamairn.Forms 轉換到 .NET MAUI 上進行。

本篇是 Re: 從零改成用 .NET MAUI 技術來繼續過去用 Xamarin 開發的一個 App : TopStore 系列 系列文的 EP09。

在經過前面 8 回的介紹，大體上已經把 TopStoreApp 的開發專案，從 Xamarin.Forms 轉成 .NET MAUI 的版本，並且可以執行到預設的四種系統平台之上，並且可能透過一統的 API 執行方式(如下圖標號 1)，運作原生平台的 API 執行(如下圖標號 3)；或是有需要可以直接在 App Code 當中直接執行原生平台的 API(如下圖標號 2)。

上圖取自微軟文件 What is MAUI。

雖然上述的運作在過去透過 Xamarin(.Forms) 與 Xamarin.Essentials 的處理時，也都可以有類似的概念完成沒錯，但 .NET MAUI 在程式架構的設計上，就顧及到很多層面，搭配 .NET 6 來重新調整底下的基底類別庫設計，大大的增加各方面的可擴充性。

Renderer v.s Handler

如果從 UI 介面其中的一個 Entry 元件來舉例好了(無論是 Xamarin.Forms 或 .NET MAUI 當中的所有的 UI 元件架構觀念皆按照此設計)。

• Xamarin.Forms 的作法採取 "Renderer"：
  
  上圖取自微軟文件 Customizing an Entry。

• .NET MAUI 的作法採取 "Handler"：
  
  上圖取自微軟文件 Customize controls with handlers。

從當代的 OO 的搭配 DP 的運用角度上來看，都會希望所設計或使用的程式庫，有著 "低耦合、高內聚、易擴充" 的特性，所以當微軟要讓 Xamarin.Forms 符合 .NET 未來的可擴充性，並符合當代的 OO 與 DP 的設計角度，對 .NET MAUI 的設計就進行了大改變。

當時 Xamarin.Forms 的 UI 元件類別設計時，在各平台實作都直接透過了類別繼承模式，(以 Entry 為例)讓各平台的 EntryRenderer 去轉置成該平台對應的原生 UI 元件。

.NET MAUI 的 UI 元件類別設計時，則透過了 ISomeUIComponent 的介面進行解耦後，(以 Entry 為例)再讓各平台的 EntryHandler 去實作該 IEntry 並轉置成該平台對應的原生 UI 元件。

改成用 Handler 的作法上是從 OOP 設計的本質上帶來了，較高的解耦性，並且可以透過 Handler 實作時讓 "重複" 撰寫的程式碼降低(相較於 Renderer)，當然如果再考慮下面要提到的 Host Builder Pattern 的時候，透過 Handler 的作法也會更加的便利根據需要來 DI 使用(雖然還是可以在 .NET MAUI 中用過去在 Xamairn.Forms 中客制開發的 Renderer 元件)。

另外，因為透過 Handler 實作 ISomeUIComponent 的介面來完成 UI 元件在平台上的轉置，所以也預留下了更好的擴充性，如果要搭配 Blazor 開發或是 Comet、Fabulous 這類 M-V-U 的開發都會相當的便捷。

而如果有興趣了解更多 .NET MAUI 的 Handlers 可以參考下面一篇微軟文件：

• Create a custom control using handlers

與下面兩篇 Doumer 撰寫的分析文章：

• Introduction to dotnet-maui
• Introduction to net-maui handlers

此外，雖然上述文章是有提到對於使用 Handler 的設計，不像過去的 Renderer 的作法需要針對整個 assembley 去做 reflection，所以執行的效能上可以更加快速。

不過，講到效能這東西就還是見仁見智，畢竟沒有真正的實驗數據去做比較是不能保證的(恩...就算有數據得比較有人還是會有意見就是)。

但 Doumer 所撰寫的分析文章，都相當有深度絕大部分的論述也都其來有自，例如下面這篇有關 Http 操作的文章就能多注意了解一下以防踩雷：

• 4 Steps To Improve HTTP Request Performance in Dotnet MAUI / Xamarin

Builder Pattern

根據過去 Xamarin.Forms 版本當中，基於過去的 .NET Standard Library 的基底類別庫，在撰寫的 XAML 或 C# 的方式(亦稱是風格?)，再透過各平台的 Xamarin 在 Native 專案透過原生應用的進入點，來執行起所設計的 Xamarin.Forms 的 App 類別。

現在 .NET MAUI 是基於 .NET 6 基底類別庫的架構模式來開發的，對於 App 的啟動也仿效了從 ASP.NET Core 開始時所使用的 Builder Pattern 設計模式，來將所設計的 App 類別透過 DI 進行物件化建立執行，並可在透過 Builder Pattern 的運用過程中，去 DI 加入其他所需的特性運用。

例如在 EP07 其中有一段提到：

來開啟 .NET MAUI 專案當中的 "MauiProgram.cs" 檔案，會注意到 MauiApp 的 Builder 已經有透過 .ConfigureFonts() 設定既有存在預設範本專案的字型檔案，在這邊變更為先前加入的 "FontAwesome5.otf" 的使用。

所以在下一回 EP 開始，就要來修正在此 TopStoreApp 的 .NET MAUI 版本中其 XAML 與 C# 的撰寫，以符合此 Build Pattern 的以及 .NET MAUI 的設計運用。

本 EP 介紹所完成的範例程式碼可在此下載 (同 EP07)。