Author:Anders小明
目前采用是面向對象設計方法,設計的粒度分為兩級:類和方法(屬性),類似于數據庫設計的表和字段;
在現有實現體系下,一個方法內部將包容多個Use Case;同時因為Use Case本身的橫向擴展,也會導致一個Use Case將關聯到多個方法;這是一個多對多的關系,為我們的開發管理帶來巨大的成本。
為了有效管理Use Case及其實現映射,AOP技術成為一個好的選擇;AOP允許我們為每個Use Case建立起獨立的可管理的設計粒度:從方法中的一個代碼段升級為一個獨立方法和類;并允許這些Use Case被合理的有序的組織。
現有的技術體系已經為我們建立了可行方案,如何組織Use Case間的邏輯操作:與,或和非操作就成為實施的關鍵。
現有實踐中,由于非業務Use Case在邏輯上的操作比較明確:與操作,執行順序上也非常明確(更換順序幾乎不影響業務正確性),AOP已有廣泛的應用;而對于業務操作由于邏輯上操作不十分明確,對于執行順序上也存在不確定性,目前缺乏合適的實踐管理;
目前采用是面向對象設計方法,設計的粒度分為兩級:類和方法(屬性),類似于數據庫設計的表和字段;
在現有實現體系下,一個方法內部將包容多個Use Case;同時因為Use Case本身的橫向擴展,也會導致一個Use Case將關聯到多個方法;這是一個多對多的關系,為我們的開發管理帶來巨大的成本。
為了有效管理Use Case及其實現映射,AOP技術成為一個好的選擇;AOP允許我們為每個Use Case建立起獨立的可管理的設計粒度:從方法中的一個代碼段升級為一個獨立方法和類;并允許這些Use Case被合理的有序的組織。
現有的技術體系已經為我們建立了可行方案,如何組織Use Case間的邏輯操作:與,或和非操作就成為實施的關鍵。
現有實踐中,由于非業務Use Case在邏輯上的操作比較明確:與操作,執行順序上也非常明確(更換順序幾乎不影響業務正確性),AOP已有廣泛的應用;而對于業務操作由于邏輯上操作不十分明確,對于執行順序上也存在不確定性,目前缺乏合適的實踐管理;
AOP做出來的切面一般是與Use Case無關的部分,如Log等。
另外你們在實際的項目中用什么技術來實現AOP?
“AOP做出來的切面一般是與Use Case無關的部分,如Log等。”這就是技術切面,包括事務,安全都是一個個UseCase;