.net - 带有状态的立面设计模式

Question

在实现了一个门面来隐藏一些复杂的子系统之后，我们最终得到了一个客户端类。但问题是这个单一的类仍然有超过 100 个 API。这似乎违反了凝聚力原则。外观类还管理状态，以便可以隐藏子系统之间使用的对象。该系统由子系统（例如项目、策略、用户、权限等）组成，我认为我们可能能够以更模块化的方式设计外观。在这种情况下，任何设计模式都可以很好地与外观配合使用吗？

Answer 1

正如您已经说过的，在一个类中拥有 100 多个 API 并不是一个好主意。它们可以分为不同的外观类。通用功能可以移动到基类。这不是设计模式，而是 OO 的核心。状态仍可维持。我不确定您是否已经在使用会话作为存储来保存状态。如果是这样，您仍然可以继续这样做。

您还可以使用缓存来存储状态或使用数据库。如果您使用的是 EJB，那么 SFSB 会提供此功能。

Answer 2

如果我们遵循领域驱动设计的原则，那么您可以将您的系统分为无状态服务和有状态实体。将服务和状态机组合在一个外观中不一定是一个好主意。

顺便说一句，在我看来，使用外观几乎就像将过程编程强制到面向对象的语言上一样。外观只是一组函数，就像非 OOP 语言中的模块一样。因此，通常我在使用 OOP 时尽量避免使用外观，尽管务实是件好事。