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中附件的操作可最終歸結為一個組件。這需要將其納入架構之中，甚至是作為架構核心服務層，視此塊的業務比重而定。演變示意結果如所示：