处理Web请求时是否存在比Front Controller Pattern更符合面向对象的替代方案

两个理念不存在冲突 #

首先要明确两类“集中控制”完全不属于同一个概念范畴，不存在本质冲突：

• 前端控制器模式的“集中”，仅针对所有请求通用的横切逻辑：包括请求路径匹配、参数序列化/反序列化、全局权限校验、异常统一处理、上下文初始化等。这些逻辑本身就不该分散在各个业务接口里重复实现，集中处理反而是符合DRY原则的设计。你给出的Spring代码示例里，DispatcherServlet作为前端控制器，本身完全不参与业务逻辑执行，只是负责将请求路由到对应的业务方法，业务逻辑完全分散在各个Controller、Service类中。
• 面向对象设计里反对的“集中控制流”，指的是将不同领域、不同职责的业务逻辑耦合在同一个类/方法中，比如把用户管理、订单处理、库存扣减的逻辑都堆在同一个上万行的类里，这才是需要避免的设计。

实际主流Web框架的前端控制器实现，本身就遵循了单一职责原则：通用逻辑归前端控制器处理，业务逻辑归各个业务类处理，和OO的分布式职责分配理念完全契合。

你给出的Spring代码示例对应的就是前端控制器模式下的业务层实现：

@PreAuthorize("hasAnyAuthority('ROLE_USER','ROLE_ADMIN','ROLE_SYSADMIN')")
@GetMapping(value = "/path/to/{id}/somewhere")
public void doIt(@PathVariable("id") String id)
{
    // ...
}

@PostMapping(value = "/path/to/{id}/somewhere")
@PreAuthorize("hasAnyAuthority('ROLE_ADMIN','ROLE_SYSADMIN')")
public SomeDto doSomething(@PathVariable("id") String id)
{
    // ...
}

@GetMapping(value = "/api/agb/check")
@PreAuthorize("hasAnyAuthority('ROLE_USER','ROLE_ADMIN','ROLE_SYSADMIN')")
public SomeDto doSomeotherthing()
{
    // ...
}

@GetMapping(value = "/api/agb")
@PreAuthorize("hasAnyAuthority('ROLE_ADMIN','ROLE_SYSADMIN')")
public List<SomeDto> getAll()
{
    // ...
}

更贴合OO设计的实现优化方案 #

前端控制器模式本身并没有违背OO设计，如果你需要对请求处理逻辑做进一步的职责拆分，可以参考以下实践：

• 命令模式封装请求：将每个请求的处理逻辑封装为独立的Command类，每个类仅负责处理单一路径的请求，自带参数校验、权限判断、业务执行的方法，前端控制器仅负责匹配到对应Command后调用execute()方法即可，比传统Controller中堆砌多个业务方法的设计职责更单一。
• 领域事件驱动处理：前端控制器收到请求后仅发布对应的请求领域事件，不直接路由调用业务方法，由对应领域的事件处理器订阅事件并执行业务逻辑，进一步降低路由层和业务层的耦合。
• 资源对象封装行为：按照RESTful的资源定义，将每个接口对应的资源抽象为独立的类，类中自带GET/POST/PUT/DELETE等请求方法的处理逻辑，前端控制器仅需将请求映射到对应资源对象调用对应方法，更贴合OO“对象自带属性与行为”的设计理念。

以上方案都是在保留前端控制器通用逻辑集中处理优势的基础上，对业务处理逻辑做进一步的OO化拆分，并不是完全替代前端控制器模式。

内容的提问来源于stack exchange，提问作者steffenb