一個優秀框架的評判標準和方向

xyz發表於2008-04-25
Java的框架很多,並且很多都是開源的。有我們熟悉的表現層框架;如;struts,jsf等;還有底層的orm框架,如hibernate,還有比較全面的框架如jboss seam等等。
縱觀這麼多框架,我們不難發現一個問題,它們很多都是面向程式設計師的,或者說是面向技術的。但是我麼要知道技術最終是要為功能服務的。我們最終是為了實現功能的,而不是為了繡技術而開發的。那麼我們的框架,一個優秀的框架最終應該以使用者需求為嚮導(而非程式設計師的需求)。
所以,是否能夠實現各種各樣的功能需求,是否能夠快速、簡單的實現許多常用的功能需求,這是首要。
Javaee一定是能夠符合企業級別開發的絕大多數需求的,要不怎麼是javaEE。但是如何能夠快速、簡單的實現許多常用的功能需求呢?
快速簡單和靈活,是比較矛盾的兩個事物。但在某種層面上是可以統一的。對於大多數常見的功能需求,我們簡單快速。對於個別的個性要求,我們靈活。
那麼具體如何統一呢?如果我們能夠把企業級開發的功能需求抽象成幾個種類,每個種類我們提供一中常用的預設解決方案。幾乎所有需求都可以歸結成這樣的幾個種類,個別個性化的要求只需要修改與預設的解決方案不太一樣的那一小部分就好了。
那麼企業級開發能否抽象成這樣的幾個種類呢?答案是肯定的。我們可是把它大致抽象成:crud,workflow,report三個種類。大多數的需求都可以歸結給這幾類,或者是這幾類的變種。
一般在系統資料的初始化的時候(包括後面的一些臺帳),都是crud功能。如人員的錄入,資料字典等等。有了這些基礎,我們的企業就可以運作了,那麼這就是workflow發揮功能了。運作了一段時間,對運作中間產生的資料做分析總結,這個就是report。如果你的workflow是bpm可能還需要重新定義流程。
所以一個好的框架——以需求為導向的框架——至少要能夠快速方便的完成crud,workflow,report三個功能。
其次我們要考慮的是效率。
再次我們再來考慮使用我們的框架後,是否能夠做到,解耦合,牽一髮而無需懂全身等等程式的效能。而這些功能是程式設計師需要的,而不是客戶需要的。但我們要記得,客戶是我們的衣食父母。
當然這個只是我的個人感受。

相關文章