求救，C#权限管理分析到很细之后，不知道怎么做了。
做一个程序，准备完善一下权限管理。初期准备如下：
1.定义一个角色，(role)
2.定义用户。
每个用户获得不同的角色，以实现权限的分配，每个角色中有不同的功能（function)

如此一来，看似完美了，一，定义好功能，再定义好角色，再让用户获得这个角色（或一个角色组）
实际还存在一个问题，那就是。

客户的需求是千奇百怪的，比如，同样一个部门，假设是采购部，那么，其中有五位员工，假设叫   emp1,emp2...emp5

现在需求是这样的。

emp1...emp5   都要能够做其中的一项功能（采购入库）

但是，emp1只能做采购方是东北的单据。

emp2只能做采购金额 <   50000元的单据，

emp3可以做采购入库操作，但是，他不能保存采购入库单，他只是做着玩，因为他是实习生。

emp3   同时也只能做东北区的业务，连查其他区的都不可以，因为这个实习生只管东北的业务，上层认为他看了其他区的也没用，可能会泄露公司的机密。

emp4   可以查东北和华东地区的业务，但只能做华东地区的，因为他刚从东北区调过来，一些业务他还要查，以确定一些诸如退货和付款等后续事宜。

上面这些，我真不知道该设计在权限里还是业务逻辑里，因为有很多相似，交叉呀什么的。谁能给我说说，这样的东西到底怎么设计才是最好的？

------解决方案--------------------
你可以这样想一下啊!

有一些是页面权限(也就是说你只要有某种权限就可以点击入相应的功能页面)
而另外一些是属于对数据的访问权限了!你可以在用户表中添加相应列,是否实习生不就OK了!

是实习生我就只给你看,不给你做,或者是可以做多少钱以内的不就哦了!


我自己也做了个相似的权限管理!
------解决方案--------------------
这个是很复杂的，.net 大概的做法是这样，user 有自己的权限定义，这是优先级最高的，user 还从 roles 中继承一些权限。权限分为两种，allow 和 deny。不过弄到一块就很复杂了，我没做过，想一想就头疼。enterprise library 里有个和权限相关的应用程序块，可以分析字符串形式的权限表达式，你找来看看有没有帮助。
------解决方案--------------------
首先分析好权限的检查跟哪些因素有关，比如从你举的例子来说主要是采购操作的时候需要进行权限的检查，相关的因素有登录用户、采购单地区、金额、操作类型。
其中采购单地区、金额等应该都是包括在采购单的信息中的，可以称为采购对象。
那么采购权限检查的输入应该由用户、操作类型、采购对象组成。比如定义一个方法bool Check(User user, Operator op, Order order)。
这个方法内部的实现可能比较复杂，可以优先检查用户权限，然后检查用户所在组的权限。
------解决方案--------------------
再新增一个权限组不就OK了
------解决方案--------------------
upup

------解决方案--------------------
发现CSDN的发贴功能很垃圾。想发一片长一点的文章都有限制先BS一下CSDN！
前言：
权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。
目标：
直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。
简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。
扩展，采用可继承在扩展上的困难。的Group概念在支持权限以组方式定义的同时有效避免了重定义时
现状：
对于在企业环境中的访问控制方法，一般有三种：
1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。
2.强制型访问控制方法。用于多层次安全级别的军事应用。
3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
名词：
粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特
定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。
细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细
粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

------解决方案--------------------
荤
------解决方案--------------------
mark
------解决方案--------------------
学习!
------解决方案--------------------
写的很好