昨天在討論完 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號"
}
這些資料若是以將這些資料傳遞到使用者介面的觀點來看，似乎有許多不必要的資料被讀出。
昨天我們重新檢視了資料庫移轉所產生物件關聯對映的資料表，以及資料表間的關聯。在檢視的過程當中也發現了原始對映出來的資料表不十分理想，因此也重新做了一些修正。既然資料庫的資料表已經有了，今天就來看看如何在資料庫的資料表中儲存資料。
上個星期五，我們第一次使用資料庫移轉將領域物件對映（Mapping）產生資料表，今天就來看看兩者的關聯對應，以及是否有需要改進的地方。
昨天已經將先前建立的領域物件以 Entity Framework Core 建立 DbContext 物件，並指定好資料庫連線字串，今天就實際學習如何對應領域物件建立出資料庫的資料表。
昨天，我們稍微體會了，為了解決某個領域上的問題，針對描述該問題（具體化該問題的行為模式）而設計出資料模型（Data Model），該資料模型在商業行為中所產生的數據需要儲存，並於適當情況被讀取、修改和刪除。
這些資料庫操作的新增、修改、刪除、查詢，一般稱為資料存取層，今天就先來學習如何將先前設計的《地址》物件對應到資料庫的資料表。
昨天已經稍微學會了依據應用程式的功能面，將程式切割成數個專案分別處理該有的功能。今天就先來學習阿源哥哥向來認為整個應用程式靈魂所在（最值錢的）的領域物件部分。