在我最近完成的一个项目中，我们使用了一个体系结构，因为它的Web /服务层的顶层交互使用了XXXManager类。
例如，有一个按计划运行的Windows服务，可将来自多个不同数据源的数据导入我们的系统。在此服务中，调用了几个“Manager”类，即CPImportScheduleManager，CPImportProcessManager等。
现在，这些Manager类不仅仅是将方法传递到链上以便在Web /服务层中使用。例如，我的UserManager.Register（）方法不仅通过较低级别的程序集保留用户，而且还向用户发送WAP推送并确定使用的移动手机等。
有人向我建议，这种类型的架构我是尝试使OOP适合程序模型的常用方法。我可以在这里看到他们的观点，但我想知道的是，使用这个顶级类的任何Web /服务层都可以简单地调用相同的常用方法而无需重写代码。因此，如果我想编写一个Web服务，在某些时候注册用户，我可以再次调用UserManager.Register（）方法，而不必再次重写所有逻辑。
我从来都不是解释自己的最佳人选，但如果我的说法有意义，请随时提出建议。
干杯，克里斯。
答案 0 :(得分：7)
管理员是一种常用的过度使用的命名策略，用于处理给定实体集的工作流或复杂任务的服务。但是，如果它完成了工作，那么它不一定是坏事。
我会遇到的重要问题是经理们面前发生了什么？如果它们简单地协调过程的工作流程，例如注册用户，那么它们是具有不同名称的控制器（MVC）。但是，如果它们包含许多业务逻辑（我的意思是条件逻辑取决于实体或实体集的状态）那么我会仔细看看是否可以通过使其成为自己上课或者把它带到有责任的班级。
更新： 从它的声音来看，你一般都有正确的想法。您有一组用于处理业务流程协调的类，这些类不关心WebService，Webform或其他任何内容是否正在使用它们。然后，您要说的是要在此基础上添加WebService层并使用这些类。这是一件好事（tm）。
答案 1 :(得分：0)
听起来你的设计动机很好 - 重用代码。在某些方面，它与Martin Fowler's Service Layer的动机相似。但是，您可能会在这些Manager类中承担过多的职责。也许从域关注（用户注册）中分离出基础设施问题（WAP推送，用户持久性）。这Separation of Concerns会进一步提高可重用性并提高可维护性。