網絡商店應用框架:DCART

jopen 10年前發布 | 40K 次閱讀 DCART 電子商務/商城

DCART 將是一個商店類的應用程序框架,它將會是一群業余愛好者開發的,更好的開源商店框架。

系統設計的想法
==============

這完全是一個業余愛好者的項目。

在用過了幾個框架,和見識了幾個開源的PHP項目之后,我想寫一個更加靈活實用的應用程序框架。
大多數的MVC框架做了基礎的工作,同時也做了一些限定,這些基礎的工作往往都很優秀,而這些限定...

好像是,我不想要使用限定好的MVC目錄結構,所以...
我嘗試在google上搜索,而找到了Silex,簡單的說Silex提供了路由,還有MVC,但是沒有更多的限定...

開發這個項目的源起,是因為想要寫一個更好的網絡商店系統,是的,謝謝opencart,它迫使我這樣想...

我發現,在這個網絡商店系統中,你想要修改它的數據流或者工作流,都相當的困難...
幾乎是,你不得不冒著破壞掉所有主題、插件的風險在做這樣的事情,而且你不得不這樣做...

所以,我想,為什么我們不能讓它更加靈活呢?讓工作流和數據流可以通過不同的模塊來在運行中動態定義和剪裁呢?

如果一個系統開發的初期,只想到了提供其所需要的特性,而不是考慮到提供開放其工作流和數據流的接口,那么...
如果一個系統,提供了其工作流和數據流的接口,是否就可以完全解決問題呢,也未必如此...

從感覺上,盡可能小的系統核心,盡可能少的工作流和數據流,以及盡可能少的依賴,似乎是必要的...
而對于,那些位于核心之外的部分,請盡可能的依賴與核心...

opencart的一個問題,就是其寫了一個功能完善的商店系統,而讓所有的主題,插件都依賴與它...
這在某點上,導致當你動了這個系統之后,別的主題插件就可能實效了...

所以,簡單,微小的核心,微小的模塊,加上微小的.....還有自我的包含和依賴,而不是過分依賴于第三方的...

我想說它應該有很多的特性,我可以想到很多,但是大多數對于目前而言,都沒有意義...

目前的主要的工作,就是確定,如何實現工作流和數據流的動態定義和裁剪...
這是一個嘗試的過程

工作流和數據流
============

到目前為止,我對于其明確的定義還是很陌生,我的概念里面,一個系統有其工作的流程,這個就是工作流吧。
工作流中會有數據的處理,所以,數據的流向可以單獨的表示出來,我叫做數據流吧。

可以看出來,我顯然是個業余愛好者...

如果一個系統有固定的工作流程,我們把它劃分為不同的部門,處理不同的工作,這個部門越小,越容易控制...
當一個部門的工作流確定之后,我們可以說,一系列的代碼執行序列確定之后,要考慮代碼中的流程控制...

例如,賣票的工作是一個流程,那么,如果我們想要在買票的這個流程之中動態的加入幾個審核票的發行方的工作流...
這樣發行方可以統計自己發行的電影有了多少票房,顯然,如果賣票這個流程已經定義,那么就要考慮給發行方一個流程接入的機制...
比如,發行方派幾個人來,然后幾張桌子,幾張椅子,統計了之后...

如果,多一步,管理者不相信賣票部門的信用,所以需要加入一個監督的人員,發現又不合適的交易,就停止...

事情變的復雜...
使用代碼你很容易形成一個樹形的工作流圖,但是對于圖的結構,就支持有限了...

這應該是另外一種隊列,而其中的每個元素的放回的結果,將被回調處理,從而能夠確定下一步的方向...
如果說其中的一系列的元素,都影響了當前的流程的走向,那么這是一個圖的方式...

組合的問題,如果這兩種放在一起做一個組合的話,又如何對待?不可能,任何一種同質的工作都在一個隊列之中,相當于一種類型的節點...

項目主頁:http://www.baiduhome.net/lib/view/home/1405734898031

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!