architecture - 经理类

Question

在我即将完成的最近一个项目中，我们使用了一种体系结构，该体系结构作为来自网络/服务层的交互的顶层使用 XXXManager 类。

例如，有一个按计划运行的 Windows 服务，可将来自多个不同数据源的数据导入我们的系统。在此服务中，调用了几个“管理器”类，即 CPImportScheduleManager、CPImportProcessManager 等。

现在，这些管理器类所做的不仅仅是将方法向上传递到链中以供在网络/服务层中使用。例如，我的 UserManager.Register() 方法不仅通过较低级别的程序集保留用户，而且还会向用户发送 WAP 推送并确定所使用的手机等。

有人向我建议，这种类型的架构是尝试让 OOP 适应过程模型的常用方法。我可以在这里看到他们的观点，但我想知道的是，对于这个顶级类集，任何 Web/服务层都可以简单地调用相同的通用方法，而无需重写代码。因此，如果我想编写一个在某个时候注册用户的 Web 服务，我可以再次调用 UserManager.Register() 方法，而不必再次重写所有逻辑。

我从来都不是解释自己的最佳人选，但如果我的胡言乱语有道理，请随时就您的替代方案提出建议。

干杯，克里斯。

Answer 1

对于处理一组给定实体的工作流或复杂任务的服务，管理器通常是一种过度使用的命名策略。但是，如果它完成了工作，那么它不一定是坏事。

我想问的一个重要问题是，在经理们的领导下发生了什么？如果它们只是协调流程的工作流程，例如注册用户，那么它们是具有不同名称的 Controller (MVC)。但是，如果它们包含大量业务逻辑(我指的是取决于一个实体或一组实体的状态的条件逻辑)，那么我会仔细查看是否可以通过将其设为自己的类(class)或将其移至具有适当责任的类(class)。

更新:从它的声音来看，你的想法大体上是正确的。您有一组处理业务流程协调的类，这些业务流程不关心它们是否被 WebService、Webform 或其他任何东西使用。然后你说你想在此之上添加你的 WebService 层并利用这些类。这是一件好事 (tm)。