Architecture 经理班

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

例如，有一个按计划运行的windows服务，它将数据从多个不同的数据源导入到我们的系统中。在该服务中，有几个“管理器”类被称为CPImportScheduleManager、CPImportProcessManager等

现在，这些管理器类所做的不仅仅是向上传递方法，以便在web/服务层中使用。例如，我的UserManager.Register（）方法不仅通过较低级别的程序集持久化用户，还向用户发送WAP推送，并确定使用的手机等

有人向我建议，这种类型的体系结构是使OOP适合过程模型的常用方法。我可以理解他们的观点，但我想知道的是，对于这个顶级类集，任何web/服务层都可以简单地调用相同的通用方法，而不必重写代码。因此，如果我想编写一个在某个点注册用户的web服务，我可以再次调用UserManager.Register（）方法，而无需再次重写所有逻辑

我从来都不是最好的解释自己的人，但如果我的胡言乱语有道理，请随时就你的选择提出建议

---

干杯，克里斯

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

我想问的一个重要问题是，管理层下面发生了什么？如果它们只是协调流程的工作流，例如注册用户，那么它们就是具有不同名称的控制器（MVC）。但是，如果它们包含大量业务逻辑（我指的是条件逻辑，具体取决于实体或实体集的状态），那么我将仔细研究一下，您是否可以通过将此逻辑设置为自己的类或将其移动到具有适当职责的类来显式化它

更新：

---

听上去，你的想法大体上是正确的。您有一组处理业务流程协调的类，这些类不关心Web服务、Web表单或其他什么东西是否正在使用它们。然后你说你想在上面添加你的WebService层并利用这些类。这是一件好事（tm）。

听起来你设计的动机是好的——代码的重用。在某些方面，它在动机上类似于。但是，您可能在这些经理类中增加了太多的职责。可能将基础设施问题（WAP推送、用户持久性）与域问题（用户注册）分开。这将进一步提高可重用性，并提高可维护性