中年大叔的鹹魚翻身作戰計畫

中年大叔鹹魚翻身作戰計畫

還記得前兩天討論的《使用者驗證與授權》中所提到的 Token Based Authentication 嗎？當使用者輸入帳號和密碼傳送到《後端》的 Web API 時，當 Web API 驗證確定為合法使用者之後，會發行一串 Token（本範例是使用 JSON Web Token），往後《前端》有任何需要授權才可以操作的請求時，都需要帶著這一串 Token 過來。

一般來講，行動裝置應用程式不會在每次啟動應用程式（或開機）之後，都要求使用者輸入帳號和密碼，並執行登入的動作，一般都會將前登入成功後所取得的 Token 再拿出來用，除非 Token 過期才會要求使用者再登入一次重新取得最新發行的 Token 。

因此，有必要先學習如何將一些與設定有關資訊儲存在行動裝置中，以為往後學習使用行動裝置應用程式，執行登入與授權的準備。

昨天我們學會了在 ASP.NET Core Web API 發行 JSON Web Token 並且使用 https://jwt.io 網站所提供的測試工具驗證所發行的 JSON Web Token 的內容確實有照我們的意思發行，今天再來學習，當《前端》拿著 JSON Web Token 回來請求任何需要授權要求的 API 服務時，如何驗證該 Token 是否有效。

昨天已經為先前實作的 ASP.NET Core Web API 加入了會員註冊與登入的功能，但是在登入的使用者認證是屬於 Cookie Based Authentication 因為我們所開發的 Web API 主要是要行動裝置使用，參考一些文章的比較，看來 Token Based Authentication 比較合適，所以今天就來學習讓我們的 ASP.NET Core Web API 可以發行 JSON Web Token 吧！

昨天在稍微了解了 ASP.NET Core Identity 會員管理機制之後，已經建立了用來記錄使用者登入以及授權旳資料庫，並將原有的控制器加上了 [Authorize] 授權要求，這樣一來，未經授權的使用者就無法使用我們所開發的 Web API 了。

但是，問題來了，那誰又是合法的授權者呢？要在什麼條件下，才可以使用呢？所以今天的學習目標就訂在《後端》的使用者註冊與登入吧！

上星期五我們在練習完刪除一筆資料前，先出現對話框詢問使用者是否確定要刪除，如果確定就執行 ASP.NET Core Web API 的刪除動作。雖然在前端有防止使用者誤按的防呆機制，但是後端的 ASP.NET Core Web API 卻沒有受到保護，只要有心人士知道 Web API 的 URL 就可以任意地操控我們的資料。

所以今天起先安排一系列與資料保護有關的練習，完成後再往下發展另外的學習。

連續一個多月都在學習由《前端》到《後端》有整體關聯的各項實作，在切換到另一項主題：《使用者驗證與授權》之前，或許切出幾個獨立小專案的基本功系列，也算是複習先前所學的。

問題：為什麼在 ViewModel 裡的屬性宣告是這樣：

private string _title;
public string Title
{
    get { return _title; }
    set { SetProperty(ref _title, value); }
}

而不是像 Entity Model 的宣告：

public string Title {get; set;}

呢？

昨天我們學到了 Prism MVVM  所提供的 PageDialogService 主要提供三揰型式的跳出對話框（Pop-ups Dialog）：

1.  用來顯示警告或是說明訊息
2.  用來讓使用者作確認選擇（是/否）
3.  用來讓使用者有多數選項的選擇

還記得先前在練習《從 Xamarin.Forms 存取 RESTful API》時，曾說明底下這段讀取 REST API 的程式不太理想。

public async void OnNavigatedTo(NavigationParameters parameters)
{
    if (Addresses == null)
    {
        try
        {
            var result = await _apiService.GetAddresses();
            Addresses = new ObservableCollection<AddressModel>(result);
        }
        catch (System.Exception)
        {
            throw;
        }
    }
}    

昨天學習了實際透過 HttpClient 由行動裝置讀取發行在 Azure Web App 的 ASP.NET Core Web API 所實作的 REST API 回傳儲存於 Azure SQL Database 資料示在 ListView 上，今天就再進一步學習如下圖所示，當按下 ListView 的項目（Item）時可將該項目所含的資料帶到下一頁，並在下一頁使用該資料的地址資訊顯示出 Google 地圖：

昨天我們學會了使用 ListView 元件在頁面導覽切換到新頁面之後，讀取資料顯示在頁面上，當時為了方面解說（想控制在 30 分鐘內講完） ，讀取資料的方法是直接寫死在程式碼當中，這不符合在真實的商業應用程式的使用情境（多人使用的系統，資料是有可能隨時變動的，有必要隨時從伺服器端讀取資料）。

因此，今天就來學習如何讀取先前發行到 Azure App Service 的那一支 ASP.NET Core Web API 程式。

上個星期五，我們學會了使用 Prism MVVM Framework 的 NavigationService 在兩個頁面之間切換，今天就來學習在切換到新頁面時，在新頁面上顯示一些東西。好吧！就學習使用 ListView 表列出先前實作的 ASP.NET Core Web API 所 Get 取得的地址資料。

昨天我們稍微地說明 Prism MVVM 的一些命名規則，以及應用程式的進入點，也說明了 View 和 ViewModel 的自動繫結，和參數的傳遞。今天就來新增幾個頁面，練習在各個頁面間切換。

本次中年大叔的鹹魚翻身作戰計畫執行至止也有一個多月了，在昨天也已經初步地完成了《後端》（也稱為伺服器端）的實作，接下來要學習的是《前端》（也稱為用戶端）的實作。在最初的幾天會先學習與 Xamarim.Forms 以及 Prism MVVM 有關的基本知識，接著會學習使用 HttpClient 由 Xamarin.Forms 應用程式（不再透過 Postman）存取 Web API 的 CRUD 動作。

昨天已經學會了在 Microsoft Azure 雲端服務平台中建立新的 Web 應用程式服務，以及 SQL Database 服務，今天就來學習如何將 ASP.NET Core Web API（往後要學的 ASP.NET Core MVC 也是相同的發行方式）發行到新建立的 Microsoft Azure 雲端服務平台。

昨天試著啟用了 Visual Studio Dev Essentials 所提供的免費 Microsoft Azure 雲端服務，今天就好好地利用這 $300.00 一年免費使用的機會，先來建立 Azure Web 應用程式的網站空間，以及 Azure SQL Database 資料庫，先將《後端》運作平台建立好，好為先前實作的 ASP.NET Core Web API 的發行做好準備吧！

在先前的幾次練習當中，我們已經完成了一個具有基本 CRUD 功能的 Web API 程式，也使用了 Postman 實際測試，並確定該 Web API 的功能正確執行。接下來似乎應該再進一步學習，如何透過行動裝置（手機或平板）存取這個 Web API 的 CRUD 功能。

但是問題來了，一般來講 IIS Express 預設是不允許本機以外的連線，必需要特別設定才可以，而對於行動裝置（就算是本機裡的模擬器）來講，連線到 IIS Express 是屬於外部連線，因此，在學習透過行動裝置存取這個 Web API 的 CRUD 功能之前，必需先將 Web API 部署到可對外連線的伺服器上才對。

還記得先前練習 Entity Framework Core 時，為了方便講解起見，直接將資料庫的連線字串直接就寫死（Hard Codding）在程式中，如下所示：

public void ConfigureServices(IServiceCollection services)
{
    var connection = @"Server=keigen;Database=DemaeDb;Integrated Security=True;";
    services.AddDbContext<DemaeContext>(options => options.UseSqlServer(connection));    
    ........        
    ........
}

還記得先前以「使用 Entity Framework 執行動作的 API 控制器」Scaffold 自動產生了 Address 物件的 CRUD 方法嗎？這種以專用模版自動套出程式碼的開發方式，對於簡單的小案子或許合適，且可以快速地完成工作，但是對於複雜的企業級應用程式就不太適合了，其中一個問題就如先前在講解 ViewModel 時所說過的，對用者介面透露過剩（或是不適宜）的資料，另一個問題就是直接在使用者介面層中（以目前的情形是在控制器中）撰寫資料存取的程式碼，這可能造成應用程式之間的耦合度過高，以及相同的程式碼重複寫好幾次的可能。為什麼會這樣呢？今天就來細說分明，並且介紹一個稱為 Repository Pattern 的設計模式（Design Pattern）

昨天在討論完 ViewModel 與 Entity 之後，我們發現當下完查詢指令，將 Entity 中的屬性對應到 ViewModel 中相對應的屬性，如果要對應的屬性一多，用手動的方式一個一個的 Coding 的話，確實是一項苦力的工作，我們寫程式的目的是要幫助企業減省人力，除去做些規則且又重複的工作。當然在寫程式的過程當中，也會希望有工具（如果有現成的，就用現成的，沒有現成的就自己開發）能幫我們做些規則而又重複的工作。為了讓我們的工作能夠輕鬆愉快，還是求問一下 Google 好了，看來這一篇有提到 AutoMapper 這項工具，看來不錯用，今天花點時間就來體驗看看吧！