订阅软件研发RSS CSDN首页> 软件研发

架构之路(八):从CurrentUser说起

发表于2015-12-14 17:25| 次阅读| 来源作者投稿| 0 条评论| 作者自由飞

摘要:本文主要讲了CurrentUser,并由此引出我们的原则:如何在View、Controller、Service和ViewModel之间划分逻辑(或者责任)。
【编者按】本文作者自由飞,具有 传奇般的人生经历

  • 98年读大学-国际贸易专业
  • 03年11月英语培训机构当英语老师
  • 04年2月-05年6月律师事务所实习和公司法务
  • 05年6月-07年12月成立装饰公司做老板
  • 08年8月开始自学编程
  • ……

伤感于 《野生程序言的故事》一文评论中同学们普遍性的自怨自艾,回顾自己求学探索的艰辛,愿意做 一些力所能及的事,帮助所有立志于自学和成长的同学。本《架构之路》系列,是他以 两个目前仍在开发的项目为例,讲解如何通过领域驱动和测试驱动,进行敏捷开发,构建一个面向对象的B/S系统的一次尝试。

同时,欢迎有兴趣的同学参与(详见: 英雄帖:开源项目招募英才)。

本文为他倾囊相授的第八篇:


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,其实可能有两种情况:

  1. View直接呈现Model的数据,比如直接显示CurrentUser的用户名
  2. 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都需要,就放进来好了。

为什么需要明确这些原则

可能你耐着性子看了上面的分析,最后却只得到一个似是而非又蛋疼的原则,会忍不住的问,“为什么一定需要/讲解这些原则?让程序员根据实际情况,自由发挥,不行么?”

浅层次的原因是要保证代码的可读性。阅读别人的代码是一件非常累的事情。但如果所有的代码都像一个人写的,而且这个人的思路自始至终都是非常清晰的,这样,我们会稍稍轻松一点。代码不是文学作品,在绝大多数情况下,不能天马行空自由发挥!

我们很多开发人员都已经开始注意代码的规范,但大多数还停留在缩进、换行、命名之类的细节(当然,这些也很重要)上;而架构师应站在一个更全局的高度,来“规范”所有的开发行为。

所以,其实更深层次的原因是:所有的代码都必须规范化。既然要规范化,那么首先就要有规范!先可以不管好坏,但至少要有。那么怎么制定完善这个规范呢?我分享一下我的经验:

  1. 按规范文档,做入职培训,培训可以着重讲道理,强化开发人员代码规范化的思维;
  2. 所有代码都必须review。review要往“挑刺”的方向靠,所以不规范的代码其实是很容易被发现的;
  3. 开发人员不服review的结果,review的人员要拿出依据(规范文档)来;
  4. 规范文档中如果还没有相关的规定,立即补充,并照此执行,包括改正以前不合规范的代码

这样不断的迭代,基本上就能不断的提高代码的规范性,并得到一份不错的规范文档。

(责编/ 钱曙光,关注架构和算法领域,寻求报道或者投稿请发邮件qianshg@csdn.net,交流探讨可加微信qshuguang2008,备注姓名+公司+职位)


「CSDN 架构师群」,内有SDCC 2015架构专场的讲师和诸多知名互联网公司的大牛架构师,如果你想进群交流,请加微信qshuguang2008申请入群,备注姓名+公司+职位。

0
0
  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章