ASP.NET ASHX 呼叫 ASPX.cs 方法：接口解耦與依賴反轉實踐

問題背景

ASHX 處理程序需調用特定 ASPX 頁面代碼後置的方法，但 ASHX 無法直接引用 ASPX 實例，且不知調用者為哪個頁面。直接引用會造成強耦合，違反單一職責原則。

解決方案：定義接口契約

public interface IPageCallback {
    string ExecuteMethod(string param);
}

ASPX 實現接口

public partial class A : System.Web.UI.Page, IPageCallback {
    public string ExecuteMethod(string param) {
        // 業務邏輯
        return "Result from A: " + param;
    }
}

ASHX 通過上下文獲取實現者

public class B : IHttpHandler {
    public void ProcessRequest(HttpContext context) {
        // 假設調用者為 A.aspx，通過 Handler 映射或 Session 傳遞實例
        // 此處為演示簡化：直接 new 實例（實際應用需依賴注入）
        IPageCallback page = new A(); // 實際不可行，僅示意
        string result = page.ExecuteMethod("test");
        context.Response.Write(result);
    }
    public bool IsReusable { get { return false; } }
}

實際可行模式：基類/服務層抽離

推薦做法：將共用邏輯提取至獨立服務類（UserService、OrderService），ASHX 與 ASPX 同樣依賴服務層，而非相互調用。

// 服務層
public class UserService {
    public string GetUserInfo(int id) { /* ... */ }
}

// ASHX
public class UserHandler : IHttpHandler {
    private UserService _service = new UserService();
    public void ProcessRequest(HttpContext context) {
        int id = int.Parse(context.Request["id"]);
        context.Response.Write(_service.GetUserInfo(id));
    }
}

// ASPX.cs
public partial class UserPage : Page {
    private UserService _service = new UserService();
    protected void Page_Load(...) { var info = _service.GetUserInfo(1); }
}

架構原則：Handler 與 Page 同層，均屬表現層入口，業務邏輯應下沉至服務層。若需共享頁面級邏輯，考慮 BasePage/BaseHandler 繼承體系或 Middleware 管道。