用户管理架构设计

转自: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.经过几次重构之后,就可以最大化的实现用户业务模型的组合、分离。上层业务模型清晰,底层基础模型清晰,后台存储模型也很清晰。
时间: 2024-10-11 23:05:10

用户管理架构设计的相关文章

菜单管理,权限管理,用户管理界面设计

提出问题! 1每个界面需要展示哪些问题? 1.1以哪种方式展示? 每个界面会进行哪些操作? 好了,带着问题进行思考,进行设计 .先来简单的用户管理界面来说,我需要展示用户(管理员)的信息. 方式是:表格形式,需要进行的是对用户的增加,删除,修改 ,模糊查询,以及赋予角色权限. 在菜单管理界面,我需要展示该用户所能操作的菜单详情,分别展示top 菜单 和top 菜单下的子菜单,和菜单项详情 ,在子菜单 的div 内添加 右键事件,在top 里面有一个新增,修改按钮,菜单项详情不可编辑,新增时弹出d

用户管理的设计--8.批量用户信息删除

页面效果 勾选一个或多个用户,或点击全选框,然后单击[批量删除],弹出确认窗口.确定则删除,取消则不删除: 实现步骤 1.JSP页面的js函数 1.1添加按钮[批量删除]单击事件触发的js函数,有两种实现方式: 1.1 DOM对象实现 DOM对象实现批量删除js 1.2 jQuery对象实现 function deleteAll(){ var $selectuser = $("input[type=checkbox][name=userID]"); var flag = false;

用户管理的设计--2.新增用户信息实现

页面效果 1.点击[添加用户] 2.弹出新界面,用于添加新的用户信息 实现步骤 1.Action类设计 (1)添加add()方法,用于加载数据字典,完成下拉选项的初始化,并跳转到新增页面 /** * @Name: add * @Description: 弹出添加用户窗口 * @Parameters: 无 * @Return: String:跳转到system/userAdd.jsp */ public String add(){ //加载数据字典,遍历性别,职位,所属单位,是否在职 this.i

权限管理架构设计及实现思路

规划权限管理至少实现菜单权限.界面权限.动作权限(按钮).服务权限. 研究如何实现数据权限等细粒度权限. (1)系统菜单管理 EF架构~性能高效的批量操作(Insert篇)

用户管理的设计--4.jquery的ajax实现登录名的校验

页面效果 鼠标失去焦点时,不需要刷新页面进行校验,判断登录名是否重复. 实现步骤 1.引入struts2-json-plugin-2.5.10.1插件包 2.页面使用jquery的ajax实现后台校验js /**校验登录名是否出现重复*/ function checkUser(o){ //alert(o.value);//dom的写法 //alert($(o).val());//jquery的写法 var logonName = $(o).val(); //以登录名作为查询条件,查询该登录名是否

用户管理的设计--6.文件下载的两种方式

页面效果 实现步骤 1.Jsp页面要求 <TD class="ta_01" align="center" bgColor="#f5fafe">附件(下载):</TD> <TD class="ta_01" bgColor="#ffffff" colSpan="3"> <s:if test="elecUserFiles!=null &

设备资源管理系统-用户管理

设备资源管理系统-用户管理 数据库设计 用户信息: 蜀国: 刘备(admin/admin),赋予超级管理员的角色. 12月1日,录入关羽的信息. 12月2日,录入张飞的信息 12月5日,张飞电话号换了,更新张飞的信息(诸葛亮更新) 2022,张飞退休了,删除张飞的信息. 特点: 是否删除:控制用户“假删除”字段. 初始状态是0,如果退休或者离职的时候设置是否删除字段为1. 注意: 1.在查询在职或者未退休的人员的时候,需要添加 where 是否删除=0. 2.如果查询已退休人员的时候,需要添加

tornado项目之基于领域驱动模型架构设计的京东用户管理后台

本博文将一步步揭秘京东等大型网站的领域驱动模型,致力于让读者完全掌握这种网络架构中的“高富帅”. 一.预备知识: 1.接口: python中并没有类似java等其它语言中的接口类型,但是python中有抽象类和抽象方法.如果一个抽象类有抽象方法,那么继承它的子类必须实现抽象类的所有方法,因此,我们基于python的抽象类和抽象方法实现接口功能. 示例代码: from abc import ABCMeta from abc import abstractmethod #导入抽象方法 class F

.NET应用架构设计—用户端的防腐层作用及设计

阅读目录: 1.背景介绍 2.SOA架构下的显示端架构腐化 3.有效使用防腐层来隔离碎片服务导致显示端逻辑腐烂 4.剥离服务调用的技术组件让其依赖接口 5.将服务的DTO与显示端的ViewModel之间的转换放入防腐层 5.1.转换逻辑过程化,直接写在防腐层的方法中 5.2.转换逻辑对象化,建立起封装.重用结构,防止进一步腐化 6.防腐层的两种依赖倒置设计方法 6.1.事件驱动(防腐层监听显示逻辑事件) 6.2.依赖注入接口 7.总结 1.背景介绍 随着现在的企业应用架构都在向着SOA方向转变,