几乎每个应用都会用到用户系统。如果能够进行通用化，自然是一种很快意的事了。然而到目前为止我还没有找到一个让我满意的类似的东西。不是说它们不够好，而在于它们不能满足管理和部署上的可伸缩性、灵活性及与现有应用的可集成性上，所以只好自己做了一个。
用户系统的组成
用户系统在设计上是有三部分组成的，用户基础信息管理、用户库管理、用户组管理。大家可能会对“用户库”和“用户组”感到疑惑，觉得不应该同时出现这两个东西，或者只用一个就可以了。然而这是为了满足“可伸缩、灵活”特征而特意设计的。下面分别就这三部分做一个说明。
用户基础信息，没有特别的，为了实现单点登录，以使各种不同的应用进行统一的用户登录验证，我们只提供简单的登录名、密码、昵称等信息。这些信息存储在中心库上。我们可以指定管理员来对整个用户数据进行管理，这对一般的应用来讲就可以了，但当一个大型的企业，每个部门都可以对自己部门进行独立的人员管理，这时就需要扩展我们的设计。
为此我提供了用户库，总部可以创建用户库，然后对用户库进行授权，让各部门管理各自的用户库，这样就实现了用户管理的独立性和伸缩性。用户库只能用于新建、编辑、删除用户，不能做其它的事情。用户库（实际上是一个表）的存储也位于中心库上。需要注意的一点是，用户库是属于平台管理的范畴，不属于某一特定的应用。
用户组只是多个不同用户或用户组的集合，用户组中的用户可以来源于任何一个用户库。它只能添加或移除用户，而不能“新建”和“删除”用户。这一点非常重要，否则用户系统的管理会非常的混乱。用户组的一个重要应用是建立一个“稳定的授权模型”，以简化管理员的工作。
用户组的复杂性和伸缩性远远超出了用户库的设计。主要有两点：
l 用户库中的数据不需要分布式存储，而用户组却需要。用户组可以有平台级的管理范畴，同时每个应用系统又都可以管理各自的用户组数据。全部将这些数据进行集中存储是不科学的，会给中心带来不必要的数据库维护任务，最好的做法就是各应用存储在各应用自己的系统库中，这就要求用户组的存储是分布式的。
l 用户库之间是平等的，而用户组之间的关系是交叉的。用户库没有父级用户库的概念，大家都是平等的。而一个用户组可能属于多个用户组。
设计要点
用户系统的设计总体上贯彻平台架构中讲到的“应用与WS分离”及“WS与数据库分离”两条宗旨。用户组的分布式存储便是一个很好的应用，我们只有一个用户组相关的WS便可以操作分布在不同位置上的数据库。
其实用户组WS和用户库WS是用的同一个WS，这就是我要给大家讲的容器系统。“容器”系统是抽象后的概念，我定义它可以管理三种结构的数据形态。
一、一维结构。容器之间是平等的，没有包含与被包含之分，如用户库系统。
二、树结构。每个容器可以有一个或零个父容器，如各种分类信息。
三、多父结构。每个容器可以有多个或一个或零个父容器，但不能形成循环，如用户组系统。
为了使用容器系统，我们必须要遵守一定的规范。
一、用容器系统提供的模板数据表进行应用数据表的创建，这里对用户库系统为每个创建的数据表名称冠以“UserLib”前辍，为每个用户组系统创建的数据表名称冠以“UserGroup”。
二、使用平台规范的自定义DBInfoSoapHeader，进行数据库信息的传递，这个类中除了包含数据库连接信息之外还提供了表名称前辍字段。这样才能在中心数据库中即能访问用户库数据又能访问用户组数据。当然对用户组来讲应用系统库中也存在着用户组数据。
用户系统中另一个共用的设计是有效时间，它允许限制用户及用户组在某一时间段内的可用性。有效时间模块用一个WS来表示，但他不直接被客户端使用，而是作为父类被其它类继承。这是因为有效时间在意义上不能是一个独立系统，另外一个重要原因在于提高系统的性能，以减少不必要的WS服务之间的访问开销，及提供事务处理功能。
我们在进行用户管理时，会经常用到“删除用户”的功能，但这个功能在用户系统中会有些麻烦。用户系统是服务于多个应用的，当删除一个用户时，与用户关联的应用数据会形成“孤儿”！如何防止此问题的发生呢？
数据依赖系统是解决此问题的专用模块。用户系统是不了解应用的业务逻辑的，这件事情只能由应用自己去处理关联的数据。不同的应用将关联关系注册到数据依赖系统中，在进行用户删除时，用户系统查询数据依赖系统中与用户关联的注册。如果存在注册，则调用所注册的处理单元，等到所有的处理单元都成功处理才能将此用户进行删除;如果没有注册,则直接进行用户的删除。不过因为时间关系,目前数据依赖系统并没有实现！只能将不需要的用户先暂时禁用了。
这里只是讲了用户系统的技术点，要让用户系统更方便的使用还要涉及到平台中的其它内容，如数据库冗余系统，WS地址服务系统等。
注意的问题
一、用户信息的扩展。
在平台用户系统中，用户信息是以保证用户能够实现统一用户验证而设计的，这同时也说明他不能全面的说明用户的基本情况，尤其是一些专业领域的系统。如银行及保险中的用户家属信息，社交网站中的兴趣爱好等。对于这些信息需要由外部应用自身来扩展。为了有好的用户体验及提供很好的集成性，用户系统提供一个“用户详细信息”的事件供应用来实现。
二、基于.NET的使用。如果应用使用.Net进行开发，那么用户只需要使用CommonWare.Dll文件就可以了。这里面已经封装了很好的客户端相关的实现。它体现了“应用与WS分离”的设计理念。
三、基于跨平台的使用。如果应用不是使用.Net进行开发，那么只好进行WS的直接调用了。