再簡單的功能，也需要一坨代碼的支持。Profile 的編輯功能主要就是修改個人的信息。比如用戶名、頭像、性別、電話……雖然只是一個編輯界面，但添加下來，涉及了6個文件的修改和7個新創(chuàng)建的文件。各種生成的和手寫的代碼，共有934行之多。
1. Account 和 Profile 分離
什么是 Account？通常這個詞被翻譯成“帳戶”。我的理解是，這個 Model 里的內(nèi)容，是為了登錄而設(shè)計的。而 Profile 呢，應(yīng)該保存那些和登錄無關(guān)的附加信息，比如昵稱、頭像之類的。不過，有一點坑的是，ASP.NET Core 默認的那個 Identify 服務(wù)把電話號碼也做為 Account 的一部分，但沒有提供通過電話來查找一個 User 的方法。雖然可以通過寫一個 Extension 來實現(xiàn)這個功能，暫時先放在一邊，有需求再說。
在原來的“悟空CRM”中，所有的信息都是放在 user 這個表里的。對于 CRM 這個應(yīng)用，也不是一個大的問題。但我認為還是應(yīng)該把 Profile 和 Account 分開。這樣，在登錄及驗證用戶權(quán)限的時候，就不需要去訪問不相關(guān)的 Profile 里的內(nèi)容。也許有朋友會說：我通過 SELECT 那些我需要的列，不也一樣可以實現(xiàn)這個結(jié)果嗎？但實際上，一個 Row 的內(nèi)容，都是保存在一起的。只是數(shù)據(jù)庫幫你過濾出來那些需要的信息。但在讀取的時候，還是要去訪問一整個 Row 的內(nèi)容。如果分開當然就完全不需要訪問了（雖然還有個 ID 在那里，但一個 ID 最多才4個字節(jié)）。
2. Repository
Repository 模式其實算是對一些使用 Plain Object 做 ORM 的系統(tǒng)的補充。按照 MVC 的實踐準則，業(yè)務(wù)邏輯應(yīng)該是寫在 Model 這一層的。但為了保持 Model 是一個 Plain Object，只能再引入一層抽象，用來嫁接 Controller 和底層的 Model。當然，使用 Repository 還有另外一個好處，就是把數(shù)據(jù)庫隔離開了。這樣，對于 Controller 的單元測試就方便多了。否則，對 Controller 里一些邏輯的測試，還需要配置數(shù)據(jù)庫。不過，有得就一定會有失。這里雖然測試 Controller 方便了，確還得對 Repository 本身時行測試。比較幸運的是，Entity Framework Core 提供了一個 InMemory 的數(shù)據(jù)庫，專門用來測試對數(shù)據(jù)庫的訪問。
通常 Repository 會包含以下這些方法：
網(wǎng)友評論
