在我即将完成的最近一个项目中，我们使用了一种架构，该架构作为来自 Web/服务层的交互的顶层使用 XXXManager 类。
例如，有一个 Windows 服务按计划运行，将来自多个不同数据源的数据导入我们的系统。在此服务中，调用了多个“管理器”类，即 CPImportScheduleManager、CPImportProcessManager 等。
现在，这些 Manager 类所做的不仅仅是将方法传递到链中以在 Web/服务层中使用。例如，我的 UserManager.Register() 方法不仅通过较低级别的程序集保留用户，而且还向用户发送 WAP 推送并确定使用的手机等。
有人向我建议，这种类型的架构是尝试让 OOP 适应过程模型的常用方法。我可以在这里看到他们的观点，但我想知道的是，对于这个顶级类集，任何 Web/服务层都可以简单地调用相同的通用方法，而无需重写代码。因此，如果我想编写一个在某个时候注册用户的 Web 服务，我可以再次调用 UserManager.Register() 方法，而不必再次重写所有逻辑。
我从来都不是解释自己的最佳人选，但如果我的闲言碎语有道理，请随时就您的替代方案提出建议。
干杯，克里斯。
最佳答案
对于处理给定实体集的工作流或复杂任务的服务，管理器是一种常用的命名策略。然而，如果它完成了工作，那么它不一定是一件坏事。
我要问的一个重要问题是，管理人员下面发生了什么？如果它们只是协调流程的工作流，例如注册用户，那么它们就是具有不同名称的 Controller (MVC)。但是，如果它们包含大量业务逻辑(我的意思是指取决于实体或实体集的状态的条件逻辑)，那么我会仔细查看您是否可以通过将其设置为显式来使该逻辑明确化自己的类(class)或将其转移到具有适当责任的类(class)。
更新:
从它的声音来看，您的想法总体上是正确的。您有一组类来处理您的业务流程的协调，这些类并不关心它们是否被 WebService、Webform 或其他任何东西使用。然后您说您想在此之上添加您的 WebService 层并利用这些类。这是一件好事(tm)。
关于architecture - 经理类，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/139034/