关于[资料(2).rar]的说明

关于(资料(2).rar)的说明

有两部份内容，一部分是权限，一部分是时间引擎。
这两部分的内容不在真实的例子中演示，很难理解，我准备写四个工作流，写了一引擎，作为例子，已写好了两个工作流，也打包传上来了。
有一天，我无聊装一个新软件(见http://www.cnblogs.com/foundation/archive/2006/12/08/586235.html),没成功，重装系统时，突然感觉资料(2).rar)的设计方案有很大的问题，就没加联接。
这几天发现有下载量，可能是有些朋友猜到了我的链接地址(^_^)

下载的朋友请注意如下内容:

本例的宿主使用的是COM+服务；
本例有四个工作流：
1.一个公文流转的工作流；
2.一个事项审批的工作流；
3.一个申请网站空间的工作流；
4.一个管理活动目录的工作流。

权限使用的是ASP.NET 20 自带的Forms模式，对AspnetDB数据库进行了扩展。

以上思路，由于没有计真规化，犯了如下错误：
1.没有认真分析权限应用场景
根限管理有两种方案，一种是使用Windows的活动目录，一种是在传统的数据库(传统的数据库是指Sql Server,因为AD也是数据库)中维用户列表。
我在设计系统是，有一个指导原则(只是指导)，那就是企业内部应用系统使用活动目录权限，商业平台(如购物网站)用数据库维护权限
而在这个例子中，我使用了数据库维护权限，这种方式在1,2流程的应用上没有问题，
在3,4流程中却非常麻烦，
[申请网站空间的工作流]的思路是客户向系统提交WEB空间的申请，管理员可以配置流程，为申请不同内容的客户分配不同的权限与磁盘配额。
[管理活动目录的工作流]的思路是管理员通过工作流可以管理局域网内的计算机。使用的是活到目录(ADSI)按制.

2.没有认直分析业务应用场景
我一向主张不要为简单公文流转写工作流引擎，可以直接在页面推，或使用SharePoint的工作流。因为开发公文流转的工作流，投入成本相对过高，而且成效不明显。我的例子也就这样，一个简单的流转，后台写的却很庞大。

3.没有全功能的工作流
这是我一向的看法，不同的工作流平台只适用特定的业务应用，而这个例子我却将不同的业务流程放到一个引擎中，倒至我的时间引擎无从入手

4.分层不好
一般作工作流设计，应分两部分，一部分是引擎，一部分是表现层。在一定的应用范围内，引擎应该是可以重用或少量修改就可以重用的，在这个例子中，我没有体理，引擎与表现层犬牙交差。

综上，这不是一个好例子。

我会重写几个有具体业务针对性的小例子[全用C#写(^_^)]。