免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

CurrentUser，也就是當(dāng)前用戶，這是我們系統(tǒng)中大量使用的一個(gè)概念。

確認(rèn)當(dāng)前用戶

當(dāng)然，我們利用的是cookie：用戶的ID存放在cookie中，服務(wù)器端通過cookie中的Id，查找數(shù)據(jù)庫，得到需要的用戶信息。

那么，這里就有一個(gè)安全問題，如何防止cookie的偽造或篡改？我們采用了以下方法：

首先，cookie中除了存放用戶Id，還存放了一個(gè)加密過后的驗(yàn)證碼，其來源如下：

• 未加密的驗(yàn)證碼在用戶生成時(shí)由系統(tǒng)隨機(jī)產(chǎn)生，并存儲在數(shù)據(jù)庫中，如：287653；
• 它會被使用MD5加密成我們看不懂的字符串，如：49b5f37dff119cf81fcb2b4e6077e17；

所以，當(dāng)服務(wù)器端使用cookie中的用戶Id時(shí)，會先檢查加密過后的驗(yàn)證碼是否有效。捏造的驗(yàn)證碼是不會通過審核的。

還有一點(diǎn)需要說明的是，我們不考慮一個(gè)有效的cookie（連同驗(yàn)證碼）被盜竊的情形。因?yàn)檫@就相當(dāng)于你的電腦被別人使用了一樣，我們確實(shí)無法判斷使用你電腦的是不是你本人。

為什么沒有使用session

可能有同學(xué)會想到，每次取cookie再查數(shù)據(jù)庫，是不是會增加數(shù)據(jù)庫負(fù)擔(dān)，為什么不考慮session呢？兩個(gè)方面的原因：

• session有定時(shí)清理機(jī)制。不管時(shí)間長短，session總有可能被清理掉的時(shí)候，這個(gè)時(shí)候不能讓用戶再重新登錄啊！多麻煩，是不是？你可以if(session["userInfo"]== null)，再通過cookie取數(shù)據(jù)再裝到session里，但何苦呢？
• session難以同步更新，維護(hù)起來非常麻煩。比如當(dāng)前用戶發(fā)表一篇文章，積分增加了，你就得既改session又改數(shù)據(jù)庫，這個(gè)同步過程是比較容易出問題的。
• 上面兩個(gè)問題，NHiernate的cache已經(jīng)做得很好了，不會增加數(shù)據(jù)庫負(fù)擔(dān)，這個(gè)以后會講。

CurrentUser的ViewModel

CurrentUser最麻煩的一件事情是：很多頁面是根據(jù)不同的當(dāng)前用戶，顯示不同的內(nèi)容的。以“任務(wù)編輯”頁面為例，當(dāng)前用戶是該任務(wù)的發(fā)布人，發(fā)布欄可編輯；否則，發(fā)布欄僅僅是可讀的。

所以，最初我們的方案很簡單，也封裝一個(gè)CurrentUserModel就可以了呀！

但后來我們發(fā)現(xiàn)：

• 需要判斷的東西越來越多，比如還要判斷當(dāng)前用戶是不是管理員、當(dāng)前用戶有沒有驗(yàn)收權(quán)限、當(dāng)前用戶的上一次操作……把這些所有的信息都裝到一個(gè)ViewModel里肯定是不合適的。怎么辦呢？想到的自然就是拆分類，但CurrentUser還怎么拆分呢？
• 頁面的判斷邏輯也變得復(fù)雜起來，比如當(dāng)前用戶有沒有某種權(quán)限得查他的申請歷史和批準(zhǔn)情況，并且還得看當(dāng)前文章是那種類型及其作者的權(quán)限等。這些大段大段的邏輯就寫在View里面么？關(guān)鍵是有些數(shù)據(jù)是單個(gè)View取不到的，需要從其他地方（比如url parameter中）獲取，這些都進(jìn)一步的增加了復(fù)雜性。讓我們不得不考慮，我們是不是應(yīng)該把這些邏輯移到Controller中，然后直接將結(jié)果告訴View，保持View的干凈清爽？

在MVC架構(gòu)中，Controller將Model傳遞給View，其實(shí)可能有兩種情況：

1. View直接呈現(xiàn)Model的數(shù)據(jù)，比如直接顯示CurrentUser的用戶名
2. View還可以利用Model中的數(shù)據(jù)進(jìn)行運(yùn)算，然后予以呈現(xiàn)，比如比較CurrentUser和當(dāng)前任務(wù)的承接人

我曾經(jīng)計(jì)劃禁止掉第2種情形，也就是說：在View里面不需要任何計(jì)算，只負(fù)責(zé)呈現(xiàn)。用代碼表示就是：

@if (Model.CurrentUserIsAccepter){
　　//CurrentUserIsAccepter的值在controller中獲取}

而不是之前的：

@if (Model.CurrentUser.Id == Model.Accepter.Id){}

但我們最終放棄了，因?yàn)閷?shí)現(xiàn)起來太臃腫了。我們可以想象，這樣的話，我們首先就至少需要三個(gè)Is屬性：

    public class EditModel    {        public bool IsAccepter { get; set; }        public bool IsOwner { get; set; }        public bool IsPublisher { get; set; }    }

有點(diǎn)怪，但好像還可以接受，但后來情況發(fā)生了變化，我們還得考慮當(dāng)前用戶即是發(fā)布人又是承接人，或者即是承接人又是驗(yàn)收人，或者既是……又是……的情形：

    public class EditModel    {        public bool IsAccepter { get; set; }        public bool IsOwner { get; set; }        public bool IsPublisher { get; set; }        public bool IsBothAccepterAndOwner { get; set; }        public bool IsBothAccepterAndPublisher { get; set; }        public bool IsBothPublisherAndOwner { get; set; }        //......    }

這代碼給人的感覺就是有病了。關(guān)鍵是，誰知道以后還來不來一個(gè)“是…和…但不是……”的邏輯呢？到時(shí)候又該怎么辦呢？

//任務(wù)編輯頁面（/Task/Edit/{taskId}）是一個(gè)頁面呈現(xiàn)邏輯比較復(fù)雜的典型例子，我們前后大改了三次，才形成今天所使用的代碼格局。//我以前說我?guī)У囊粋€(gè)妹紙看著代碼哭，哭的就是這里，呵呵//有興趣的同學(xué)可以研究一下。

所以，取巧是不行了，我們還是得面對這個(gè)問題：

如何劃分Controller和View之間的邏輯/責(zé)任？

更直白一點(diǎn)的講，哪些事該Controller做，哪些事該View做？這個(gè)問題真的超級虐心。我想來想去，只能說：“能Controller做的，盡量讓Controller做”。我自己對這個(gè)問題都相當(dāng)不滿意，但實(shí)在是沒有辦法啦。

具體到CurrentUser的ViewModel，我們提出以下兩個(gè)原則：

• 不包含需要和其他對象交互運(yùn)算才能得到的數(shù)據(jù)，比如當(dāng)前用戶是不是當(dāng)前任務(wù)的發(fā)布人，需要和“當(dāng)前任務(wù)的發(fā)布人”做比較，就不能包含進(jìn)來
• 只能是需要多個(gè)View共用的數(shù)據(jù)，才能放進(jìn)來。比如用戶名，很多View都需要，就放進(jìn)來好了。

為什么需要明確這些原則

可能你耐著性子看了上面的分析，最后卻只得到一個(gè)似是而非又蛋疼的原則，會忍不住的問，“為什么一定需要/講解這些原則？讓程序員根據(jù)實(shí)際情況，自由發(fā)揮，不行么？”

淺層次的原因是要保證代碼的可讀性。閱讀別人的代碼是一件非常累的事情。但如果所有的代碼都像一個(gè)人寫的，而且這個(gè)人的思路自始至終都是非常清晰的，這樣，我們會稍稍輕松一點(diǎn)。代碼不是文學(xué)作品，在絕大多數(shù)情況下，不能天馬行空自由發(fā)揮！

我們很多開發(fā)人員都已經(jīng)開始注意代碼的規(guī)范，但大多數(shù)還停留在縮進(jìn)、換行、命名之類的細(xì)節(jié)（當(dāng)然，這些也很重要）上；而架構(gòu)師應(yīng)站在一個(gè)更全局的高度，來“規(guī)范”所有的開發(fā)行為。

所以，其實(shí)更深層次的原因是：所有的代碼都必須規(guī)范化。既然要規(guī)范化，那么首先就要有規(guī)范！先可以不管好壞，但至少要有。那么怎么制定完善這個(gè)規(guī)范呢？我分享一下我的經(jīng)驗(yàn)：

1. 按規(guī)范文檔，做入職培訓(xùn)，培訓(xùn)可以著重講道理，強(qiáng)化開發(fā)人員代碼規(guī)范化的思維；
2. 所有代碼都必須review。review要往“挑刺”的方向靠，所以不規(guī)范的代碼其實(shí)是很容易被發(fā)現(xiàn)的；
3. 開發(fā)人員不服review的結(jié)果，review的人員要拿出依據(jù)（規(guī)范文檔）來；
4. 規(guī)范文檔中如果還沒有相關(guān)的規(guī)定，立即補(bǔ)充，并照此執(zhí)行，包括改正以前不合規(guī)范的代碼

這樣不斷的迭代，基本上就能不斷的提高代碼的規(guī)范性，并得到一份不錯的規(guī)范文檔。

好像寫跑題了，又是項(xiàng)目管理方向的東西。就先這樣吧！前臺的架構(gòu)，想想，剩下的應(yīng)該就是單元測試（都還沒做，所以暫時(shí)也講不了），還有可能其他一些細(xì)節(jié)了，以后查漏補(bǔ)缺吧。接下來希望參與到項(xiàng)目的前臺開發(fā)的同學(xué)就可以開始聯(lián)系我了。博客系列我們將接著講Service層。