下图为今天设计脚本管理模块时采用VS2005随手画的结构图
对脚本管理有如下构想:
1、 脚本存储分多种方式(当前设计考虑支持文件存储<每个文件一个脚本而非所有脚本存储在同一文件>&数据库存储)
2、 要求脚本管理系统实现与存储系统解耦,即使得脚本管理对存储系统透明,脚本管理系统不必知道如何存储
3、 脚本能够UNC唯一,AIO要求脚本可以相互调用,设计UNC是为了能够正确调用正确的脚本
4、 脚本可以实现多种分类方式,支持多种目录结构(即同一个脚本可以属于多个目录<称其为链接目录Linked Catalog>,而脚本实际仅存储于单个目录<称其为UNC目录或一般目录UNC Catalog>)
忽然觉得该结构可以引申为文件系统,同一个文件可以存在于多个链接目录、链接目录可以包含链接目录和一般目录以及文件,考虑一下在现有文件系统之上在实现一个虚拟的文件系统(在现有基础上增加链接目录系统、链接系统包含文件的方式可以采用文件系统中的快捷方式实现、可惜快捷方式不能够嵌套<内容中包含多个快捷方式>否则文件系统就自己支持了)。
如果有该系统支持的话可以有如下场景:
1、 系统再也不会出现一个文件到处都存在的情况了,一个文件只有一个存储位置,但是却有多种表现方式
2、 多个项目包含同一个文件也可以在项目视图中看到该文件仅属于该项目了,不必再将其到处拷贝了或者被动的将其放到公共目录了(公共目录破坏了系统的逻辑表现方式)、也不必为了拷贝单个项目文件而漏拷公共目录或为一两个文件而拷贝整个公共目录等
3、 不再为资料的存储和分类发愁了(不必多说了,都烦分类,今天放这里,明天放那里,整天搬来搬去总觉得放哪都不太合适,最后导致可能到处都有,也可能自己也忘记放那里了)
4、 该构想也可以在内容管理系统中借鉴。
说的比较乱 不过我想大概意思应该都明白了吧。