在最近的项目中，我几乎完成了使用的架构，该架构的顶层是与Web /服务层进行交互的顶层使用XXXManager类。

例如，有一个按计划运行的Windows服务，该服务将从几个不同的数据源中导入数据到我们的系统中。在此服务中，几个" Manager"类称为CPImportScheduleManager，CPImportProcessManager等。

现在，这些Manager类所做的不只是将方法向上传递给Web /服务层中的对象。例如，我的UserManager.Register()方法不仅通过低级程序集持久化用户，而且还向用户发送WAP推送并确定所使用的手机等。

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

我从来都不是解释自己的最佳人选，但如果我的观点有道理，请随时为我们提供替代方案的建议。

干杯，克里斯。

解决方案

经理是一种通常被过度使用的命名策略，用于处理给定实体集的工作流或者复杂任务。但是，如果能够完成工作，则不一定是一件坏事。

我要问的重要问题是管理者下面发生了什么？如果只是简单地协调了流程(例如注册用户)的工作流程，那么它们就是名称不同的控制器(MVC)。但是，如果它们包含很多业务逻辑(我的意思是条件逻辑取决于实体或者一组实体的状态)，那么我会仔细看一看，是否可以通过使其逻辑明确来使之明确自己的班级或者以适当的责任将其移至班级。

更新：
从它的声音来看，我们总体上有正确的想法。我们有一组处理业务流程协调的类，这些类不在乎WebService，Webform或者其他对象正在使用它们。这就是说，我们想在此之上添加WebService层并利用这些类。这是一件好事。

听起来我们进行该设计的动机是良好的代码重用。在某些方面，它的动机类似于Martin Fowler的服务层。但是，我们可能在这些Manager类中承担了太多的责任。也许将基础设施关注点(WAP推送，用户持久性)与域关注点(用户注册)分开。这种关注点分离将进一步提高可复用性，并改善可维护性。