還記得前兩天討論的《使用者驗證與授權》中所提到的 Token Based Authentication 嗎？當使用者輸入帳號和密碼傳送到《後端》的 Web API 時，當 Web API 驗證確定為合法使用者之後，會發行一串 Token（本範例是使用 JSON Web Token），往後《前端》有任何需要授權才可以操作的請求時，都需要帶著這一串 Token 過來。
一般來講，行動裝置應用程式不會在每次啟動應用程式（或開機）之後，都要求使用者輸入帳號和密碼，並執行登入的動作，一般都會將前登入成功後所取得的 Token 再拿出來用，除非 Token 過期才會要求使用者再登入一次重新取得最新發行的 Token 。
因此，有必要先學習如何將一些與設定有關資訊儲存在行動裝置中，以為往後學習使用行動裝置應用程式，執行登入與授權的準備。
昨天我們學到了 Prism MVVM 所提供的 PageDialogService 主要提供三揰型式的跳出對話框（Pop-ups Dialog）：
還記得先前在練習《從 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 的發行做好準備吧！
還記得先前練習 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 這項工具，看來不錯用，今天花點時間就來體驗看看吧！
昨天我們實際使用 Postman 測試了先前實作的地址 Web Api 的 CRUD 功能，但是在列表以及查詢時得到如下格式的資料：
{
"id": 3,
"areaId": 4,
"area": {
"id": 4,
"name": "三民區",
"cityId": 6,
"city": {
"id": 6,
"name": "高雄市",
"areas": []
}
},
"line": "漢口街302號"
}
這些資料若是以將這些資料傳遞到使用者介面的觀點來看，似乎有許多不必要的資料被讀出。
昨天有針對使用 Scaffolding 自動產生的地址的 CRUD 動作方法，配合 RESTful 的說明稍微地了解了一下，今天會再進一步對照程式碼，使用 Postman 實際驗證一下執行的結果。
昨天使用了 Scaffolding 自動產生 Web API 控制器的動作方法，可以對地址（Address）物件做新增、修改、刪除，以及查詢的動作，今天就來一面深入查看這些工具自動產生的程式碼的內容，並實際操作體驗和測試這些，新增、修改、刪除，查詢的功能是否可以正常運作。
昨天興高采烈地試著使用 Scaffolding 自動產生 Web API 控制器的動作方法，但是卻發生了如下圖所示的錯誤：
看來是將 Domain Model 與 DbContext 分開成兩個專案所造成的，解決的方法就是重改架構將這兩個專案合併成一個，否則就是自己動手寫。幾經思量之後決定修改架構，所以今天就來試看看怎麼改。
昨天已經將跟地址有關的基礎資料建立完成，今天就來利用這些資料來建立 Web API 與地址有關的新增、修改、刪除、查詢等功能。
昨天我們重新檢視了資料庫移轉所產生物件關聯對映的資料表，以及資料表間的關聯。在檢視的過程當中也發現了原始對映出來的資料表不十分理想，因此也重新做了一些修正。既然資料庫的資料表已經有了，今天就來看看如何在資料庫的資料表中儲存資料。
