怎么查网站的备案,茶叶网站flash模板,郑州的网站建设,南京最新发布CurrentUser#xff0c;也就是当前用户#xff0c;这是我们系统中大量使用的一个概念。 确认当前用户 当然#xff0c;我们利用的是cookie#xff1a;用户的ID存放在cookie中#xff0c;服务器端通过cookie中的Id#xff0c;查找数据库#xff0c;得到需要的用户信息。 …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的人员要拿出依据规范文档来规范文档中如果还没有相关的规定立即补充并照此执行包括改正以前不合规范的代码这样不断的迭代基本上就能不断的提高代码的规范性并得到一份不错的规范文档。 好像写跑题了又是项目管理方向的东西。就先这样吧前台的架构想想剩下的应该就是单元测试都还没做所以暂时也讲不了还有可能其他一些细节了以后查漏补缺吧。接下来希望参与到项目的前台开发的同学就可以开始联系我了。博客系列我们将接着讲Service层。 转载于:https://www.cnblogs.com/freeflying/p/5018787.html
