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