我們開發產品,並且這些產品具有以EJB實現的業務邏輯。想法是提供一個用戶出口(用戶可以覆蓋默認行爲的擴展點)。這應該是產品開發中的常見問題,但我沒有看到任何設計模式或抽象機制來支持用Java編寫的業務邏輯的覆蓋。設計考慮在軟件產品中有用戶退出
用戶出口可以是重寫的Bean類或Groovy腳本。是否有任何設計模式或設計注意事項來開發可以使用某些Java類或腳本覆蓋EJB的產品?
使用AspectJ可以做任何事情來動態地決定應該使用默認實現還是應該使用用戶特定實現中的方法(重寫用戶出口代碼)?
我們開發產品,並且這些產品具有以EJB實現的業務邏輯。想法是提供一個用戶出口(用戶可以覆蓋默認行爲的擴展點)。這應該是產品開發中的常見問題,但我沒有看到任何設計模式或抽象機制來支持用Java編寫的業務邏輯的覆蓋。設計考慮在軟件產品中有用戶退出
用戶出口可以是重寫的Bean類或Groovy腳本。是否有任何設計模式或設計注意事項來開發可以使用某些Java類或腳本覆蓋EJB的產品?
使用AspectJ可以做任何事情來動態地決定應該使用默認實現還是應該使用用戶特定實現中的方法(重寫用戶出口代碼)?
面向方面編程是要走的路。使用Spring 3或Plain AspectJ的AOP使用戶能夠覆蓋現有的功能。
有關更多信息,請參閱AspectJ in Action book。
希望對某人有用。
根據你的意見,我會推薦策略模式來實現可插拔邏輯算法。
然後使用像Spring這樣的IOC容器來連接這些類。
允許用戶/客戶端根據自己的需要覆蓋此配置。所以任何感興趣的人都可以簡單地實現你的接口並覆蓋配置,這樣應用程序就會使用這些數據。
EJB本身現在具有依賴注入,因此您可能也想要查看它。如果這些條款足夠的話,你可能根本不需要彈簧來連接你的應用程序。不幸的是我不熟悉他們知道自定義配置是否可能。
您是否希望用戶能夠覆蓋您的EJB功能? – Thihara
它不一定是一個用戶,它可以是一個配置團隊或客戶服務團隊。不僅僅是EJB,它可以是任何類。 EJB覆蓋就是其中之一。 –
這通常聽起來像一個壞主意。不是某些事件鉤子能夠提供您需要的功能嗎?如果你想要的話,你可以允許配置一些bean覆蓋,如果你使用DI/IOC ...... – Thihara