《业务代表模式》｜J2EE企业架构模式

关键词：Business Delegate、业务代表、解耦表现层与业务层、降低耦合、J2EE模式
说明：业务代表模式不属于GOF23设计模式，属于J2EE企业架构模式

一、什么是业务代表模式

业务代表模式（Business Delegate Pattern）：用于解耦表现层（UI/Controller）和业务服务层。表现层不直接调用远程业务服务，通过业务代表（Business Delegate）作为中间代理。
业务代表封装查找、创建、调用业务服务的复杂逻辑，屏蔽业务服务的定位、远程调用细节。表现层只依赖业务代表，不需要感知EJB、远程服务等底层实现。

核心意图
隔离表现层与业务服务；将业务服务查找、实例获取、调用异常处理交给业务代表，简化前端控制器代码。

角色划分

Client（客户端/表现层）：如Controller、UI层，调用BusinessDelegate
Business Delegate（业务代表）：对外提供业务方法，内部查找并调用BusinessService
Lookup Service（查询服务）：负责查找、定位业务服务，服务工厂
Business Service（业务服务）：业务接口，包含业务方法；可以有本地/远程实现（如EJB）
Concrete Business Service（具体业务服务）：业务逻辑实现

数据流：
Client → BusinessDelegate → LookupService → BusinessService

二、UML结构图

角色划分：

Client：表现层代码，依赖BusinessDelegate
BusinessDelegate：持有BusinessService引用，接收客户端请求
LookupService：服务查找器，获取业务服务实例
BusinessService：业务服务抽象接口
ConcreteBusinessService：业务服务具体实现

三、Java完整示例

场景：订单业务服务，表现层通过BusinessDelegate调用订单服务。代码全部使用英文。

// Business Service
public interface BusinessService {
    void doTask();
}

// Concrete Business Service
public class OrderService implements BusinessService {
    @Override
    public void doTask() {
        System.out.println("OrderService: process order business logic");
    }
}

public class PaymentService implements BusinessService {
    @Override
    public void doTask() {
        System.out.println("PaymentService: process payment business logic");
    }
}

// Lookup Service
public class LookupService {
    public BusinessService getBusinessService(String serviceType) {
        if ("ORDER".equalsIgnoreCase(serviceType)) {
            return new OrderService();
        } else if ("PAYMENT".equalsIgnoreCase(serviceType)) {
            return new PaymentService();
        }
        return null;
    }
}

// Business Delegate
public class BusinessDelegate {
    private LookupService lookupService = new LookupService();
    private BusinessService businessService;

    public void setServiceType(String serviceType) {
        businessService = lookupService.getBusinessService(serviceType);
    }

    public void doTask() {
        businessService.doTask();
    }
}

// Client
public class Client {
    public static void main(String[] args) {
        BusinessDelegate businessDelegate = new BusinessDelegate();

        businessDelegate.setServiceType("ORDER");
        businessDelegate.doTask();

        businessDelegate.setServiceType("PAYMENT");
        businessDelegate.doTask();
    }
}

运行输出：

OrderService: process order business logic
PaymentService: process payment business logic

四、业务代表模式 vs DAO模式

模式	作用	分层位置
Business Delegate	隔离表现层 ↔ 业务服务层	Web层与业务层中间
DAO	隔离业务层 ↔ 数据库持久层	业务层与数据库中间

五、优缺点总结

✅ 优点

解耦表现层和业务服务，客户端无需感知服务查找与实例化
集中管理业务服务的查找、异常处理
业务服务变更，客户端代码不需要改动
减少表现层与远程业务服务之间的网络调用次数

❌ 缺点

增加额外中间层，少量增加代码复杂度
多一层转发，轻微增加调用链路
现代Spring开发中，依赖注入已经替代LookupService，原生业务代表使用变少

六、框架应用场景

经典J2EE / EJB体系架构（当年用来访问远程EJB业务组件）
早期Java Web项目，表现层需要调用远程业务服务

现代SpringBoot开发，IOC容器承担了LookupService的职责，业务代表模式很少手写；但其思想依然保留，常用在网关、远程服务代理场景。

七、小结

业务代表模式核心：业务代表作为表现层与业务服务之间的代理，封装服务查找和调用细节，客户端只调用业务代表，不和底层业务服务直接耦合。

归属：J2EE架构模式，不属于GOF23。