文件管理系统设计方案_系统概要设计包括哪些内容

系统规划

组织内共享文件，形成网络磁盘，可用于多个业务用途，如电子文档共享、知识库等。

通常包括以下功能：
文件夹管理：新增、删除、更名、查看（这里是指查看下级文件夹及文件）
文档管理：上传、下载、更名、在线预览、删除（还可以扩展签入、签出、打印……）
权限控制：这里是专用的数据权限，权限项是相对固化的
在线预览：实现文档的在线预览，需支持pdf和office等常见格式

其中权限控制和在线预览是难点和重点。

该功能比较复杂，分成几个迭代来实现。
1.实现基本的文件夹和文档管理
2.实现权限控制
3.实现在线预览

方案设计

文件夹和文件共用业务实体还是相互独立？

从技术角度分析，文件夹与文件是两个业务实体，有不同的属性和操作。
从展现角度和习惯而言，如参照windows系统资源管理器的模式，需要混合展现，例如选择某一文件夹后，需要显示该文件夹下的文件夹与文件。

经综合考虑后，设计方案如下：
文件夹与文件采用两个独立的业务实体。
为方便用户操作，采取前端左树右表的布局模式，在文件夹树上可进行新增、删除和更名等操作。
左侧显示文件夹树，点击某节点后，右侧显示该文件夹下的子文件夹和文件，不分页，这种方式与windows系统更相似，但逻辑实现和操作相对复杂一些，需要根据用户当前选择的对象类型（文件夹还是文件）来进行不同的操作，例如，用户选择几个文件夹和文件后执行复制和移动操作。

排序问题

对于文档管理下的文件夹和文档，都是动态变化的，不适合添加排序号字段来排序，参照SharePoint，按名称升序排列，如用户需要排序，则可以人为添加如01，02……或A、B……等前缀来实现排序目的。

对于文档，如默认按名称排序，则会发生一个问题，即新上传的文档，可能随机插入到了当前列表中间问题，这样容易让用户产生未上传成功或找不到的“错觉”，因此更改文档的默认排序规则为按创建日期降序排列。

文档更新冲突问题

对于团队内共享的文档，面临的一个问题是文档更新可能存在覆盖的问题，需要系统进行控制。不少文档管理系统的实现方式是参照源码管理工具svn的思路，即如果要更新文档，先签出，锁定文件，然后再签入，释放锁，两步操作才能完成更新，对用户来说比较繁琐也难以理解。

大多数场景文档主要用来查看和下载，更新的情况比较少，特别是多人更新同一文档的情况更少。
因此考虑以下更优方案：
如用户人为判断该文档可能多人同时编辑，存在冲突的可能，则可以在自己编辑的时候，先进行加锁操作，自己更新完后再释放锁，这种做法实际也是svn的一种操作模式（例如对于全局配置文件）。

对于解锁操作，是否要控制必须加锁人来解除？正常情况下应该是这样，但实际运行过程中，往往存在加锁人忘记解锁的情况存在，这时除了允许管理员解锁外，应该也允许有该解锁功能权限的用户去操作，可以配合管理制度，更改文档前看下是否为锁定，若为锁定，线下沟通确认是否在编辑过程中，如不是，则仍可以解除锁定，上传更新文档。

也就说是，这里的锁定仅是提示提醒功能，而不是严格限定不能更新文档，在线下沟通确认未处于编辑状态（如忘记解锁或短时间无法更新文档），则仍可以解锁和更新。

功能设计

文件夹

构建树

不控制访问权限和是否显示，所有文件夹全部显示。
树的加载方式有两种，一是一次性加载所有，二是采用懒加载模式，初始化构建根目录和二级模式，用户点击时加载下级节点。

初始实现了懒加载模式，有以下几个不太好的地方：
1.点击节点时el-tree控件会自动加入加载中的图标效果，但是……正常情况下加载速度很短，一闪而过反而形成闪烁和抖动效果，而一次性加载的方式展开子文件夹会很流畅。
2.对节点的动态修改不是太好控制，以及效果较差，后来对创建和重命名文件夹也做了功能重构，不在树上操作。
3.考虑到即使大型公司，文件夹的总数量也是有限的，大约是几千数量级，这个级别尚不会对浏览器和后端造成压力。

基于以上几点考虑，树的构建方案进行调整，将懒加载变更为一次性加载。

新增与改名

树节点右键菜单触发，完成后通过调用el-tree的api，对前端树进行新增节点和更改节点内容操作。

删除

树节点右键菜单触发，后端调用框架删除操作，前端调用el-tree的api，对树进行节点移除操作。

移动

树节点右键菜单触发，后端变更库表记录的上级，不对相应的关联文件存储进行移动（磁盘文件无需变动位置），需验证是否具备当前文件夹移动权限，以及目标文件夹的创建文件夹权限。

此外，这里移动操作实际上只是修改父级标识，内部会调用文件夹的修改操作，而修改操作又会验证是否具备更名权限，这个地方隐含授权要求。
已进行优化，实现独立的更名操作，将权限验证放在更名操作中，避免权限隐含带来的使用上的复杂性。

复制

树节点右键菜单触发，后端变更库表记录的上级，相应的关联文件存储进行拷贝，需验证是否具备当前文件夹复制权限，以及目标文件夹的创建文件夹权限。

文档

查询

框架常规查询功能，可根据文件名称搜索，默认按上传日期降序排列。

上传

复用平台技术组件，前端vue-simple-uploader，后端oss，模块定义为edoc，实体类型定义为document，统一存储。

下载

复用平台文件下载能力。

复制

实现与文件夹类似，逻辑更简单一些，只考虑文档自身即可，复制文件夹功能实际内含复制文档操作，支持批量。

移动

实现与文件夹类似，逻辑更简单一些，只考虑文档自身即可，移动文件夹功能实际内含移动文档操作，支持批量。

删除

常规实现，注意，考虑到文档的重要性，此处删除只是将库表记录标记删除标志位，并且保留磁盘文件，因此实际会出现文件删除，但磁盘占用不变少的情况，如有需求，可以追加功能，即磁盘清理，遍历数据库中标记为删除的记录，将对应的文件从磁盘中真正删除。

更名

基于框架实现，只修改名称。

更新

上传新文档，生成新版本，插入版本信息。

锁定

更改文档状态为锁定，并设置锁定人和锁定时间。

解锁

更改文档状态为正常，并清空置锁定人和锁定时间。

分享

生成访问令牌，指定访问时效，允许通过令牌预览和下载文档。

文档类型

为了提升人性化，需要显示友好的文档类型名称，主要依托文件后缀名来实现。

某些文档可以归为同一类，例如doc和docx都可以归为word。
划分的颗粒度需要规划，例如word、excel和ppt又可以统称为office。

先按大类进行划分，日后如有需要可进一步拆分：

office：“docx”, “wps”, “doc”, “xls”, “xlsx”, “ppt”, “pptx”
图片：“jpg”, “jpeg”, “png”, “gif”, “bmp”, “ico”, “raw”
文本：txt,html,htm,asp,jsp,xml,json,properties,md,gitignore,log,java,py,c,cpp,sql,sh,bat,m,bas,prg,cmd
代码：“java”, “c”, “php”, “go”, “python”, “py”, “js”, “html”, “ftl”, “css”, “lua”, “sh”, “rb”, “yml”, “json”, “h”, “cpp”, “cs”, “aspx”, “jsp”
压缩包：“rar”, “zip”, “jar”, “7-zip”, “tar”, “gzip”, “7z”
多媒体：mp3,wav,mp4
markdown：md
xml:xml
pdf:pdf
flv:flv
cad:cad

文档类型的存储，原本计划使用数据字典，灵活可以配置，但字典有名称唯一性验证，文档类型实际就是多个编码（这里是指文件后缀）对应同一名称，例如，doc和docx都对应word文档，jpg和png都对应图片，这个地方如去掉名称唯一性验证肯定影响正常数据字典功能使用。将文件后缀作为名称存储，而把类型名称作为编码存储，同样面临的是编码唯一性验证。

如果单独为文件类型建库表，做单独维护又有点小题大做，如果放在代码里相当于硬编码，不方便扩展。

考虑到变动频率较低，放在配置文件里，应用程序启动时，加载到内存。

注意：java的properties类型的配置文件，包括增强版的ini，要求必须对中文转码，巨坑，更改为yml，utf-8编码。

此外，文档类型在上传环节，根据文件后缀名，通过配置信息的转换，获取到类型名称，写入到数据库字段中，而不是类似数据字典，库表存放编码，显示环节再转换。

收藏夹

用户可以将文档或文件夹收藏，以便快速访问。
收藏功能处于边缘端功能，无需投入过多设计过于复杂，简便使用最佳。

需求评估

1.文档收藏：功能实现简单
2.是否需要分组：有分组后对于用户而言更方便一些，实现复杂些，暂不考虑实现分组功能，后续可优化
3.文件夹收藏：从业务操作而言，用户收藏某文件夹，往往关注该文件夹下所有内容，不仅仅是直接下属文档，而且还包括子文件夹。
4.是否需要对收藏项命名？不需要，只保留标识关联，当对应的文件夹或文档重命名后，自动显示最新的名称。
5.是否需要排序？不需要，收藏夹通常很少，以后可做优化。

功能设计

收藏项相关
列表
添加
移除

文档相关
查看文件夹：跳转到文档库，自动展开当前文件夹
预览文档：调用预览
下载文档：调用下载

权限控制

作为人性化功能，不做权限控制，默认允许所有用户使用收藏相关功能

版本

需求评估

文档的重要特性之一就是不断更新，版本管理非常重要，保留版本历史，可以查看过往修改历史，可进行版本恢复。

方案设计

1.版本格式

按照三级模式，创建时默认为1.0.0，更新文档时第三级,默认加1，允许用户手动指定，系统验证版本号要高于当前版本。

2.版本回退

方案：
处理方式1：将选中版本作为最新版本，同时删除该版本后续版本信息
处理方式2：提取选中版本的文档路径，替换当前版本
处理方式3：将选中版本拷贝一份，作为最新版本，自动版本标记（如：还原1.2.1版本）

评估
方式1相当于“硬”回退，会丢失文档的历史变更记录；
方式2会丢失当前版本对应的文档，用户无法“反悔”
方式3则会保留所有文档历史记录。

结论
选择第三种处理方式，命名设置定恢复版本，比回退版本更适合

3.文档相关操作

1.上传文档时，自动生成文档初始版本1.0.0。
2.复制文档时，自动生成文档初始版本。
3.更新文档时，弹出窗口，上传文档，系统自动生成的版本号、用户可调整，可添加文档标记。

功能设计

创建版本
查看版本列表
恢复版本：提取选中版本的文档路径，自动生成新版本文档和版本标记

以下操作禁止
删除版本信息

开源资料

系统名称：一二三文档管理系统
简介： 企事业单位一站式文档管理系统，让组织内文档管理有序，协作高效、安全可控
资料：csdn专栏
开源地址：Gitee
开源协议：MIT
欢迎收藏、点赞、评论，你的支持是我前行的动力。

今天的文章文件管理系统设计方案_系统概要设计包括哪些内容分享到此就结束了，感谢您的阅读。