码迷,mamicode.com
首页 > 其他好文 > 详细

用户管理架构设计

时间:2015-01-04 22:44:36      阅读:182      评论:0      收藏:0      [点我收藏+]

标签:

转自:http://virusswb.blog.51cto.com/115214/1111442

  

今天给大家分享的是:用户管理模块

或者说用户管理子系统如何设计,包括如何抽象以及相关的存储。

 

大部分的应用中都会有用户的概念,除非你的网站全部是匿名访问,不保存用户任何信息。其实这也是不好的,因为你的网站如果没有用户的概念,没有设计用户模块,就很难收集用户信息及用户行为,也就很难有数据来分析用户的喜好,也就少了一条给用户提供更好服务的途径。

现在是web2.0的时代,甚至是web3.0,用户越来越在意网站给自己带来的内容,显示的内容是否合适自己,而且用户很想参与网站的内容构建,想要对自己构建的内容进行聚合、管理。

说了这么多,就是要说明用户管理模块很重要,是个应用就应该考虑,而且还是重中之重。

先来看一下用户信息都包含哪些内容。

常见的内容包括:登录账号,登录密码,电子邮箱,个人网址,手机,QQ,简介,标签等等。

用户还可能包括企业用户,就会有:企业名称,企业注册号,企业工商号,企业营业执照号,法人,联系人,联系人职务等等企业信息。

如果是涉及到金钱往来的应用,例如:电商网站。肯定还会有银行账户信息:开户银行名称,开户名称,开户账号等。

用户会有很多的类型。

有的是个人,有的是企业。

有的有银行账户信息,有的没有银行账户信息,现在没有的,以后可能会有。

在用户认证方面现在可能是username/password,以后可能需要支持第三方认证(例如:微博,twitter,qq),还可能需要SSO。

 

单用户模型,单表存储模型

最开始想到的是就是一个用户模型,然后把所有的属性都建立在这个模型上,然后加上个用户类型属性区分一下。不同的用户类型,使用不同的属性。

在存储方面就建立一张表,每个属性来一个字段。虽然有很多的字段在一些情况下会有浪费,甚至在用户量巨大的情况下,是非常浪费的。但是好处就是从模型到存储,都是唯一的,来源唯一,省去一些获取啊,类型转换之类的麻烦。

但是也带来另外的一些麻烦,就是在代码中需要做很多的判断。什么类型,使用那些字段。

 

多用户模型,多表存储模型

上面的存储太浪费了,而且不清晰,所有用户都在一张表中,看起来有点不爽。

好吧,分开吧,根据用户类型分开,每个用户类型一个模型,单独存储一张表。

个人用户:登陆账号,登录密码,电子邮箱。

企业用户:登陆账号,登录密码,企业名称,组织机构代码,企业法人。

这下好像清晰了一点,需要什么类型的用户就用那个用户的模型,就去那张表找。

但是有几个问题:

1.登陆都是用username/password,在两张表,难道写两遍,但是都一样啊。好吧,也有解决办法,那就是写一个数据库视图,在视图中连接两张表,查询视图就可以了。这样也解决了一些需要同时查询所有用户的场景,不错。但是随着用户类型的增加,需要维护数据库视图,否则查询结果就会产生误差。但是查询单个类型用户的时候,是直接用表呢?还是用视图呢?有点纠结了!

2.需要增加银行账户信息,有几类用户需要添加,有的不需要添加。好吧,打开需要添加的表和模型,添加一下,但是有重复的工作量,是不是可以更好一点呢?

 

 

 !!!

其实我有一点感悟,就是你的代码写的和业务越是贴近,它的复用性就会越低,就是和某种业务绑定了,甚至是和某一个业务点耦合了。

当然,有的时候会有这种需要,这段代码就是为这个业务点来服务的。

但是有很多时候不是这样的。

举个例子吧。

一个实体有很多的状态,有几个状态来来决定是否能进行某个操作,你可能会写这样的一个方法。

private boo CanUpdate(Status status)

{

    if(status==Status.Wait||status==Status.Finish)

    { return true;}

    return false;

}

当上面的wait和finish状态还同时决定其他操作的时候,你可能又会写一个方法CanDo。这两个方法就有一些重复,可能在定义一个中间状态,复用一下会更好也说不定。

这个例子也可能不太合适,也可能是命名的问题。这个地方还需要大家拍砖,最好是使劲儿的拍,拍醒我,拍明白我。

 

 

 

信息模型,按信息类型存储

看到标题,很多人肯定是糊涂了,说着用户怎么就不提用户的事儿了呢?

其实就是抽象一下,用户就是一种信息。

在经历过几次用户信息的扩充之后,思考一下,把所有的信息都罗列出来,看看他们到底如何建立模型,如何设计存储,才能更好的适应应用的发展。

从另外一个角度,跳出应用,跳出业务划分,单纯的从信息的属性看看,是否有解决办法。

 

我觉得可以这么划分

  • 验证信息:登录账号,登录密码,电子邮箱。
  • 基本信息:姓名,联系电话,手机,所在地。
  • 个人类信息:证件类型,证件号码。
  • 企业类信息:企业名称,法人,组织机构代码,企业登记号。
  • 银行账户信息:开户行名称,开户行所在地,开户行账户名称,开户行账户号码。

应用中的业务用户类型,都可以从这几种信息中组合而来,而且随时可以增加一类信息。用户信息的底层基础模型分为几个,分开独立存储。

业务中中某一类用户,需要哪些信息,就从用户信息的底层模型中挑选那几个,组合成一个业务的用户模型,进行业务的操作。

甚至底层基础模型还可以做到对业务模型屏蔽存储结构,存储方式,存储类型。

 

这么做有几个好处:

  1. 1.你可以把所有用户的验证信息存储在一起,这样在username/password验证,以及增加第三方验证的时候,都会很方便。
  2. 2.大量消除空白字段,节约存储空间。
  3. 3.大量消除重复字段,防止遗漏。
  4. 4.经过几次重构之后,就可以最大化的实现用户业务模型的组合、分离。上层业务模型清晰,底层基础模型清晰,后台存储模型也很清晰。

用户管理架构设计

标签:

原文地址:http://www.cnblogs.com/sunteng-change-control/p/4202265.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!