架构之路（八）：从CurrentUser说起
- 98年读大学-国际贸易专业
- 03年11月英语培训机构当英语老师
- 04年2月-05年6月律师事务所实习和公司法务
- 05年6月-07年12月成立装饰公司做老板
- 08年8月开始自学编程
- ……
伤感于 《野生程序言的故事》一文评论中同学们普遍性的自怨自艾，回顾自己求学探索的艰辛，愿意做 一些力所能及的事，帮助所有立志于自学和成长的同学。本《架构之路》系列，是他以 两个目前仍在开发的项目为例，讲解如何通过领域驱动和测试驱动，进行敏捷开发，构建一个面向对象的B/S系统的一次尝试。
同时，欢迎有兴趣的同学参与（详见： 英雄帖：开源项目招募英才）。
本文为他倾囊相授的第八篇：
- 第七篇： 《架构之路（七）：MVC点滴》；
- 第六篇： 《架构之路（六）：把框架拉出来 》；
- 第五篇： 《架构之路（五）：忘记数据库》；
- 第四篇： 《架构之路（四）：测试驱动》；
- 第三篇： 《架构之路（三）：单元测试》；
- 第二篇： 《架构之路（二）：性能》；
- 第一篇： 《架构之路（一）：目标》。
CurrentUser，也就是当前用户，这是我们系统中大量使用的一个概念。
确认当前用户
当然，我们利用的是cookie：用户的ID存放在cookie中，服务器端通过cookie中的Id，查找数据库，得到需要的用户信息。
那么，这里就有一个安全问题，如何防止cookie的伪造或篡改？我们采用了以下方法：
首先，cookie中除了存放用户Id，还存放了一个加密过后的验证码，其来源如下：
- 未加密的验证码在用户生成时由系统随机产生，并存储在数据库中，如：287653；
- 它会被使用MD5加密成我们看不懂的字符串，如：
49b5f37dff119cf81fcb2b4e6077e17；
所以，当服务器端使用cookie中的用户Id时，会先检查加密过后的验证码是否有效。捏造的验证码是不会通过审核的。
还有一点需要说明的是，我们不考虑一个有效的cookie（连同验证码）被盗窃的情形。因为这就相当于你的电脑被别人使用了一样，我们确实无法判断使用你电脑的是不是你本人。
为什么没有使用session
可能有同学会想到，每次取cookie再查数据库，是不是会增加数据库负担，为什么不考虑session呢？两个方面的原因：
- session有定时清理机制。不管时间长短，session总有可能被清理掉的时候，这个时候不能让用户再重新登录啊！多麻烦，是不是？你可以if(session["userInfo"]== null)，再通过cookie取数据再装到session里，但何苦呢？
- session难以同步更新，维护起来非常麻烦。比如当前用户发表一篇文章，积分增加了，你就得既改session又改数据库，这个同步过程是比较容易出问题的。
- 上面两个问题，NHiernate的cache已经做得很好了，不会增加数据库负担，这个以后会讲。
CurrentUser的ViewModel
CurrentUser最麻烦的一件事情是：很多页面是根据不同的当前用户，显示不同的内容的。以“任务编辑”页面为例，当前用户是该任务的发布人，发布栏可编辑；否则，发布栏仅仅是可读的。
所以，最初我们的方案很简单，也封装一个CurrentUserModel就可以了呀！
但后来我们发现：
- 需要判断的东西越来越多，比如还要判断当前用户是不是管理员、当前用户有没有验收权限、当前用户的上一次操作……把这些所有的信息都装到一个ViewModel里肯定是不合适的。怎么办呢？想到的自然就是拆分类，但CurrentUser还怎么拆分呢？
- 页面的判断逻辑也变得复杂起来，比如当前用户有没有某种权限得查他的申请历史和批准情况，并且还得看当前文章是那种类型及其作者的权限等。这些大 段大段的逻辑就写在View里面么？关键是有些数据是单个View取不到的，需要从其他地方（比如url parameter中）获取，这些都进一步的增加了复杂性。让我们不得不考虑，我们是不是应该把这些逻辑移到Controller中，然后直接将结果告诉 View，保持View的干净清爽？
在MVC架构中，Controller将Model传递给View，其实可能有两种情况：
- View直接呈现Model的数据，比如直接显示CurrentUser的用户名
- View还可以利用Model中的数据进行运算，然后予以呈现，比如比较CurrentUser和当前任务的承接人
我曾经计划禁止掉第2种情形，也就是说：在View里面不需要任何计算，只负责呈现。用代码表示就是：
@if (Model.CurrentUserIsAccepter){ //CurrentUserIsAccepter的值在controller中获取}而不是之前的：@if (Model.CurrentUser.Id == Model.Accepter.Id){}但我们最终放弃了，因为实现起来太臃肿了。我们可以想象，这样的话，我们首先就至少需要三个Is属性： public class EditModel { public bool IsAccepter { get; set; } public bool IsOwner { get; set; } public bool IsPublisher { get; set; } }有点怪，但好像还可以接受，但后来情况发生了变化，我们还得考虑当前用户即是发布人又是承接人，或者即是承接人又是验收人，或者既是……又是……的情形： 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; } //...... }这代码给人的感觉就是有病了。关键是，谁知道以后还来不来一个“是…和…但不是……”的逻辑呢？到时候又该怎么办呢？//任务编辑页面（/Task/Edit/{taskId}）是一个页面呈现逻辑比较复杂的典型例子，我们前后大改了三次，才形成今天所使用的代码格局。//我以前说我带的一个妹纸看着代码哭，哭的就是这里，呵呵//有兴趣的同学可以研究一下。所以，取巧是不行了，我们还是得面对这个问题：如何划分Controller和View之间的逻辑/责任？
更直白一点的讲，哪些事该Controller做，哪些事该View做？这个问题真的超级虐心。我想来想去，只能说：“能Controller做的，尽量让Controller做”。我自己对这个问题都相当不满意，但实在是没有办法啦。
具体到CurrentUser的ViewModel，我们提出以下两个原则：
- 不包含需要和其他对象交互运算才能得到的数据，比如当前用户是不是当前任务的发布人，需要和“当前任务的发布人”做比较，就不能包含进来
- 只能是需要多个View共用的数据，才能放进来。比如用户名，很多View都需要，就放进来好了。
为什么需要明确这些原则
可能你耐着性子看了上面的分析，最后却只得到一个似是而非又蛋疼的原则，会忍不住的问，“为什么一定需要/讲解这些原则？让程序员根据实际情况，自由发挥，不行么？”
浅层次的原因是要保证代码的可读性。阅读别人的代码是一件非常累的事情。但如果所有的代码都像一个人写的，而且这个人的思路自始至终都是非常清晰的，这样，我们会稍稍轻松一点。代码不是文学作品，在绝大多数情况下，不能天马行空自由发挥！
我们很多开发人员都已经开始注意代码的规范，但大多数还停留在缩进、换行、命名之类的细节（当然，这些也很重要）上；而架构师应站在一个更全局的高度，来“规范”所有的开发行为。
所以，其实更深层次的原因是：所有的代码都必须规范化。既然要规范化，那么首先就要有规范！先可以不管好坏，但至少要有。那么怎么制定完善这个规范呢？我分享一下我的经验：
- 按规范文档，做入职培训，培训可以着重讲道理，强化开发人员代码规范化的思维；
- 所有代码都必须review。review要往“挑刺”的方向靠，所以不规范的代码其实是很容易被发现的；
- 开发人员不服review的结果，review的人员要拿出依据（规范文档）来；
- 规范文档中如果还没有相关的规定，立即补充，并照此执行，包括改正以前不合规范的代码
这样不断的迭代，基本上就能不断的提高代码的规范性，并得到一份不错的规范文档。
（责编/钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，交流探讨可加微信qshuguang2008，备注姓名+公司+职位）
「CSDN 架构师群」，内有SDCC 2015架构专场的讲师和诸多知名互联网公司的大牛架构师，如果你想进群交流，请加微信qshuguang2008申请入群，备注姓名+公司+职位。