ECB模式实现：类交互逻辑与静态类使用合理性咨询

一、你的客户插入流程完全符合ECB模式规范 #

先给你吃个定心丸——你规划的这套流程完美契合ECB（Entity-Control-Boundary）模式的核心职责划分：

• Boundary层（CustomerWindow）：只负责和用户交互、收集输入数据，不涉及业务逻辑或数据处理，完全符合边界类“隔离外部与系统内部交互”的定位；
• Control层（CustomerController）：作为中间协调者，接收边界层的请求，完成数据校验、实体对象创建，再调用数据访问层完成持久化，承担了ECB中控制类“协调用例执行、整合各层资源”的核心职责，没有越界处理UI或持久化细节；
• Entity层（Customer）：作为纯数据载体（也可包含自身基础业务逻辑，比如字段格式的基础校验），专注于封装客户数据，符合实体类“代表业务领域对象”的定义；
• CustomerDAO：虽然不属于ECB的三个核心角色，但作为基础设施层的持久化组件，由控制类调用是合理的——控制类负责整合所有必要资源来完成业务用例，不需要直接处理持久化细节。

二、不建议将CustomerController、CustomerDAO设为静态类 #

静态类看似方便（无需实例化即可调用），但会带来很多长期维护的痛点，更推荐使用实例类：

• 测试难度飙升：静态方法无法被mock，比如你想测试CustomerController的校验逻辑时，没法模拟CustomerDAO的行为，只能依赖真实数据库，测试效率和可靠性都大打折扣；
• 扩展性极差：如果后续需要支持多种数据源（比如从MySQL切换到MongoDB），或者给Controller添加新的依赖（比如日志组件、缓存服务），静态类的硬编码调用会让修改变得非常繁琐；
• 线程安全隐患：如果静态类中持有任何状态（比如连接池对象、配置参数），多线程场景下很容易出现并发问题；
• 违背面向对象设计原则：静态类无法实现继承、多态，也不支持依赖注入，会让代码耦合度变高，不符合开闭原则。

如果担心实例化的开销，其实轻量级对象的实例化几乎没有性能成本。你可以通过依赖注入（比如在CustomerController的构造函数中注入CustomerDAO实例），或者用容器管理单例（比如给类添加单例逻辑）来保证对象复用，同时保留灵活性。

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