BPM和Portal项目中上传下载删除附件的演变

整个项目分为BPM部分和Portal部分，期间都涉及到附件的上传、下载和删除。在BPM部分，附件永远是作为流程附件而存在的，故而这块的内容无论流程的多少，其可作为一种附件信息存入DB的一个Table，只是多了一个流程Id的标示即可，而旁的信息可以设置在各自的流程VWAttachment中（参见:http://blog.csdn.net/dongzi87/article/details/7163679）。由此其关于附件的业务操作变少了许多，从而可简单的形成一个流程附件上传组件，结合架构示意图如下所示：

上图仅展示流程部分附件操作的流程，其与流程自身的业务是独立的。而portal中附件的操作与相关信息的业务则不是独立的。这一点是有需求定义确定的，因为工作流和portal对附件要求各有不同，其在架构中的体现也自然有所不同。

在portal信息业务处理中伴随着附件上传删除，而portal后台管理中所涉及的每个功能模块对业务要求不一，故而可是附件上传删除服务形成特定组件，如下示意图所示：

BPM中附件上传、下载、删除三个服务均有一个组件形成，而在Portal中附件的上传和删除是伴随有其他业务的，这一点在BPM中用户是分时期处理的。所以采用了上图形式，而下载过程则又不包含其他业务成分了，故而又演变回类似于流程部分附件操作内容。示意图如下所示：

结合这几组图以及BPM和Portal中业务与附件操作，容易发现它所要的不是入口地址的确定（是从业务对应的Action处入手，还是从附件组件的Action处切入），而是对业务的封装：附件操作时不带有其他业务；附件操作前后会带有其他业务操作。抽象到此处则可以套用一些模式上的内容，下图简要展现这一思路：即可有业务操作的附件操作，也可无业务操作的附件操作，全凭实现类（具体业务）决定。

上面仅为示意，可能根据需要也许会置换文件操作和业务操作的位置。总之，BPM和Portal中附件的操作可最终归结为一个组件。这需要将其纳入架构之中，甚至是作为架构核心服务层，视此块的业务比重而定。上图演变示意结果如下图所示：