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