什麼是 AOP 系列之二：以切面實作權限控制的最佳實踐

傳統權限控制的兩大流派與痛點

1. 應用層硬編碼/代理模式

在每個業務方法前插入權限檢查，或為每個業務類別建立代理類別。缺點明顯：業務邏輯與權限邏輯強耦合、擴充修改困難；代理類別雖解耦但從角色維度看涉及類別過多，維護成本高。

2. J2EE 容器標準實作

EJB 規範定義聲明式安全，由容器負責權限驗證，應用僅需配置部署描述檔。雖簡化應用設計，但靈活度受限於容器實作，移植性存疑。

AOP 賦予權限控制的新維度

AOP 引入後，權限控制演進為兩大方向：

1. 容器級 AOP 化：如 JBoss 4.0，開發者可在應用中直接操控容器行為，容器與應用透過切面融合。
2. 應用層純 AOP 實作：不依賴特定容器，以標準 AOP 框架（如 AspectJ）實作，解決移植風險，但需自行建構完整權限模型。

實戰重構：以 AspectJ 實作 Jive 論壇權限控制

步驟 1：定義權限檢查切面

private static aspect PermissionCheckAspect {
    private pointcut permissionCheckedExecution() :
        execution(public Forum ForumFactory.createForum(String, String));

    before() : permissionCheckedExecution() {
        if (!permissions.get(ForumPermissions.SYSTEM_ADMIN)) {
            throw new UnauthorizedException();
        }
    }
}

切面邏輯：在 createForum 執行前檢查權限，無權則拋出異常。業務類別完全無感知。

步驟 2：切點表達式簡化與擴充

若多個方法需同權限，可用 || 串聯，或以通配符簡化：

private pointcut permissionCheckedExecution() :
    execution(public * ForumFactory.*(..));

一行涵蓋 ForumFactory 所有公有方法，極大降低維護成本。

深度思考：角色模型與 Hard Code 消除

原始 Jive 程式碼將權限與使用者硬編碼。引入「角色」概念，建立 User-Role-Permission 三層模型，配合切面動態解析權限，可將業務邏輯與安全策略徹底解耦，實現真正的聲明式安全。

遷移建議與總結

• 現有 J2EE 專案可漸進式引入：先以切面處理橫切權限邏輯，保留容器管理認證。
• 新專案若採用 Spring AOP/AspectJ，可構建純應用層權限框架，擁有完全控制權與可移植性。
• 切面粒度設計原則：按「業務功能分類」或「安全等級」劃分切點，避免過度碎片化。

AOP 使權限控制從「程式碼散落」轉為「集中聲明」，是企業級應用安全架構演進的關鍵里程碑。