1 、 简介、数据库的总体结构
2 、 介绍人员表组
3 、 介绍组织结构表组
4 、 介绍角色表组
5 、 介绍“项目自我描述表组”
6 、 权限到节点
7 、 权限到按钮
8 、 权限到列表（表单、查询）
9 、 权限的验证
10 、 资源方面的权限
11 、 角色管理的程序（给客户用的）
12 、 权限下放
13 、 个性化设置
写到第六章终于迎来了热烈的讨论，不过讨论的焦点好像和角色的关系不是很大。第一个焦点是数据库的设计是否符合三范式。这个我承认，确实不符合。这个我都有点不敢往下写了，看一下表结构，Role_Role -> FunctionIDs ，Role_RoleButton ->ButtonIDs ，Role_RoleColumn -> ColumnIDs，Role_RoleResource -> ControlCaseIDs，四个表都有这种设计。如果要改的话，那么我就需要再增加三个表，Oracle用四个表就搞定了，而我这一增加就加了三个。本来就有人说我的表多了，又要加上三个，我可如何是好？你说我能不郁闷吗？哎，怎么又带情绪了，什么时候能改呢？
第二个焦点是“拒绝角色”。以前大家都没有听说过，顶多听说过拒绝操作。好像大家都不接受。
因为我不是直接给用户设置操作权限，而是通过角色来间接实现的。所以我也不能直接把拒绝操作设置给用户。
如果说“可以操作”的集合叫做角色的话，那么“拒绝操作”的集合应该叫什么呢？我给起的名字就是“拒绝角色”。大家好像不太接受，那么我想请大家帮个忙，看看“拒绝操作”的集合应该叫什么好？
我想改一个大家能接受的名字就可以了吧。
======================
好像写了这么多并没有给大家一个总体的印象，那我就尝试通过一个小故事来说一下吧。讲理论我实在是不在行，咱讲例子吧。
比如一家牛肉面馆，主要卖牛肉面，老板为了让牛肉面的口感更好一些，提供了四种配料：香菜、葱花、辣椒油、醋。老板觉得这四个都没什么特别的，就告诉大厨，每一样都放进去一点。这样就是一个“牛肉面 + 四种配料”的方案。
开张之后来了四位顾客，看了牛肉面的介绍后开始点餐。他们要了四份牛肉面，第一份不要葱花，第二份不要香菜，第三份不要辣椒油，第四份不要醋。因为每个人的口味都不一样，也可能会有忌口的。那么提出这样的要求也没有什么。老板一想，客户虽然挑剔了一点，但是也没什么的。于是就告诉大厨客户的需求。
于是配料方案就变成了这样。
这里的不放香菜，就是一种“拒绝”，在原有的配料方案的基础上，去掉某一种配料，而形成一种新的配料方案。就是说你放了其他的我都不管，只要不放香菜就行。 用“拒绝”的方式，有时候表述起来比较清楚。如果上面客户的需求不用拒绝的方式来说，就会有些啰嗦。来四份牛肉面，第一份放香菜、辣椒油、醋，第二份放葱花、辣椒油、醋，第三份放香菜、葱花、醋，第四份放香菜、葱花、辣椒油。这样子一口气说出来，恐怕服务员就记不住了，当然也可能服务员的记忆能力很强能够记住。但是还是很啰嗦。
当然了，并不是所有的情况都适合使用拒绝的情况，比如下面的四位顾客。
又来了四位顾客，也是点了四份牛肉面，第一份只放香菜，第二份只放葱花，第三份只放辣椒油，第四份只放醋。老板想呀，今天是什么了，怎么客户都是这样呢。但是没办法，客户就是上帝呀。于是吩咐大厨照做。
这样的配料方案就是：
这个就是组合，把公用的拿出来，然后把特殊的单独列出来，最后根据不同的人的需求，选择适合的组合在一起。
两个图和在一起
这回老板想了，这下没问题了吧。可是又来了四位顾客。也是要了四份牛肉面，第一份只放香菜和辣椒油，第二份只放辣椒油和醋，第三份只放葱花和醋，第四份只放辣椒油和葱花。这回老板哭了。这客户也太难答对了呀。忽然老板急中生智，奔向厨房，告诉大厨，以后做好牛肉面后，什么配料都不放了。然后又去吩咐服务员，给每张桌子放上四个小碗，分别放上葱花、香菜、辣椒油和醋，哦，还是用瓶子装醋吧。最后告诉客户，我们提供了四种配料，你们可以依据口味自己添加。
提供一种主食——牛肉面，提供四种配料——香菜、葱花、辣椒油、醋。让客户自行选择。
什么，您问如果有20位顾客，他们要的牛肉面都是完全一样的，难道让这20个人每个人都说一遍需求吗？这个就可以拿出来那个配料方案了，只不过这个配料方案不是有饭店提供，而是让顾客自行设置。比如让顾客找个代表出来，让他来指定配料方案（相当于管理员，由他来设置角色）。
一开始老板的思路就是预先做配料方案，根据自己的经验和一些客户的需求来制定一个可以适合大部分情况使用的方案，然后让客户去选择。但是后来客户的各种各样的需求都上来了，哪一个都得答对好，都得满足。哪个客户能够得罪的起呢？于是就不断的修改自己的配料方案以满足需求。最后老板实在是顶不住了，把饭店可以提供的配料罗列出来，让客户自己去选择。这样饭店只需要提供单一的配料，其他的就不管了，把皮球踢给了客户。
最后一种情况就是我的权限的思路了，就是我的项目提供基本的单一的功能，然后让客户自己去选择、组合。
而我的思路是这样的，我把功能“切成小片”，让客户（管理员）自己去组合成角色。而这个“小片”就以功能节点、按钮，甚至是字段、过滤条件的形式体现。而这些都列了个目录放在了表里面。（不知道我说清楚了没有）
============================================================================
在重新整理一下表，如果只有用户和权限的话，是下面的这个图。一个用户可以有多个权限，一个权限也可以有多个用户。
因为可能有许多人拥有相同的权限，一一给每个人设置比较麻烦，于是就引入了Role，通过Role来简化一下操作，同时也便于维护。如果权限有变化，那么只需要修改Role就可以了。用户和角色是多对多，角色和权限也是多对多。
然后在引入Group，这个就有一点复杂了，Group并不仅仅是组织机构，还可能是工作组，也可能是其他。既然引入了Group，那么他就有可能和组织机构有一些关联。下面是我的一种理解。
这样用户甲就可以通过部门来找到角色A。就是说不用在次给用户甲分配角色A了。
还有一个就是工作组，我想工作组就是角色的集合吧。一个用户拥有多个角色，那么就通过工作组来简化操作。
最后就是权限，又回到了老问题，权限到底是什么？
我现在的设计是把权限分成了操作和资源两部分，然后操作又变成了功能节点 + 按钮的形式。而资源变成了字段（是否可用）和过滤条件，而过滤条件又分为列表过滤（GridView这一类的）和控件过滤（DropDownList这一类的）。
下面这个图好像有点乱。
其实现在想一想，功能节点、按钮、字段这些不也可以看成是一种资源吗？就是说权限就变成了，对“资源”有没有使用的权力。这里的资源是一个广义上的资源，包括节点、按钮、页面、字段、数据、过滤方式（查询条件）等等。这样子的话，我不就只需要三个表了吗？用户表、角色表、资源权限表，哦忘记了两个关联表。用户和角色的关联，角色和资源的关联。这样就是五个表了，和那个传说中的Orcale的四个表就差一个表了。恩，那个两个关联表是不是也可以合并成一个呢？合并了之后就确确实实变成了四个表了。
不管我的这四个表和Orcale的四个表是不是一样的，总之我是不喜欢这种为了减少表而把类似的都给挤到一个表的方式。我还是会用我的好多表的方式。至少在没有发现中大问题之前是不会改的。
====================================
最后再说一下回复，我怕不说明的话，会没有人来回复，没有人来条我的毛病。我是希望大家来挑毛病的，但是您不能只说个结论就完事了吧，再说点论据和论证好吗？我就是一code，希望的是具体的东东，空洞的、泛泛的、没有实际意义的，我是很烦的。比如那个，因为 表的数量 > 4 ，所以我就是瞎搞，就是没弄明白设什么是权限。这叫什么呀？！
另外我希望我们以朋友、同事、同学、程序员的身份来讨论，大家共同提高嘛！
