用户管理架构设计

 

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

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

 

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

现在是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.经过几次重构之后，就可以最大化的实现用户业务模型的组合、分离。上层业务模型清晰，底层基础模型清晰，后台存储模型也很清晰。