onlyoffic及第三方预览编辑服务开发，本文章针对业务流程脱敏后的文章

原来业务代码和逻辑的弊端总结：

因为涉及到公司业务流程，这里就不发原来的业务流程了。大体上就是代码冗余度太高，操作数据库频繁。预览一次需要转换的文件，总计需要查找数据库17次，更新数据表13次，插入数据6次。增加了数据库系统的压力和对整体性能都不友好，因此采用新的开发流程进行重构流程和简化代码。

可行性方案前提说明：

1、因为我们平台的文件都是一次性调用接口完成所有的流程，因此可以理解为除了转换服务是多线程，其他均可由单线程操作控制完成，整个流程是串行的,访问文件在一次会话中完成。
2、因为文件的属性信息都是由cns（控制服务）生成，包括md5、objKey、fileName、fileSize、src、水印信息的配置。我们可以根据src的信息通过file.exists()判断文件是否存在。
3、基本上所有公司的平台都可以这样进行设计

可行性评估：

根据FFE（预览编辑服务简称）对接第三方和自己的适配页面可知，实际上我们只需要把必要的参数和文件传给页面，页面就会自动实现预览效果了

新的预览文件流程图：

流程细节补充说明：

1、在第七步的时候会启用redis记录转换任务，并发场景，当同样的文件进行点击预览的时候，就不会出现重复进行转换任务。当多线程执行完转换任务后，有返回结果，将redis的数据清除
2、拿到转换后的结果或者不需要转换任务的结果，再开启下一步下载文件接口的生成，这样就保证整个流程在一次会话中是同步的，也就是一次预览执行一次以上流程即可。
3、以上流程的设计依赖于BSM传递的SRC位置，在我们系统上适用。但是如果为了平台拓展性，可以增加一个字段，控制是否依赖BSM(存储的服务组件)的SRC位置，采用使用CNS文件的创建位置也行，但是要保证同一个文件传递过来的位置是一致的。
4、在位置的基础上，会加上filesize和md5进行判断文件是否完整和是否是同一个文件。
5、由于使用src和md5和file进行控制，有一种极端特殊的情况，平台在文件在下载的时候崩溃了，会导致文件不会重新下载，这个时候在页面提供一个清除缓存的按钮，让客户重新发起预览请求.

代码设计的技术可行性评估说明（以onlyoffic为例子说明）：

1、我们需要对接的参数包含如下：fileType（文件类型）、key（预览的id）、title（文件名字）、permissions（文件权限）、url（文件下载地址）、user.id（用户的id）、user.name（用户的名字），ffe只要传递这些自定义的参数即可完成第三方页面的渲染并显示。
2、多线程采用Future返回结果，替代原先的多线程技术（原来的多线程依赖数据库），如图

代码的设计：

技术架构：采用redis，springboot、多线程、ddd领域设计模式、java的适配器设计模式和建造者模式

设计的代码说明：

1、取消原来的map接收参数，使用对象进行接收从cns传递过来的参数
2、采用ddd领域贫血的设计思想模式设计代码的结构，结构简易和便于维护
3、采用java的设计模式进行控制和适配代码的逻辑
代码设计类图如下：

类图说明如下：

viewFileInfoDO：作为接收前端参数的对象
VIewController：restful接口入口
viewService：VIewController控制层流程控制下的viewService业务层的服务
convertSerview：转换的服务
bsmService：BSM的业务实现层，实现具体的存储操作
PlatformUtil：平台的工具类
viewFileInfoVO：返回给业务层的对象属性
getTargetView(in viewFileInfoDO)：根据文件格式和配置得到访问的目标预览方式和需要转换的属性
getTargetFIle(in viewFileInfoDO)：得到最终文件的属性，该方法组合转换的服务进行文件转换
getViewFileInfoVO(in viewFileInfoDO)：得到文件最终视图对象属性
doConvert(in viewFileInfoDO)：进行转换的方法
PlatformUtil：平台的工具类，用于获取平台的控制参数，如Nacos或者cns的类
getControlParam()：获取平台控制参数的方法，包括nacos和cns等等
设计思想，Controller只做简单的逻辑控制，service层实现具体的业务，文件的类目录结构采用领域设计模式进行分层