3

在我几乎完成的一个最近的项目中，我们使用了一种架构，它与 Web/服务层的交互使用 XXXManager 类作为其顶层。

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

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

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

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

干杯，克里斯。

4

2 回答 2

7

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

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

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

于 2008-09-26T12:20:45.020 回答
0

听起来你的设计动机很好——代码的重用。在某些方面，它的动机类似于Martin Fowler 的服务层。但是，您可能在这些 Manager 类中堆积了太多的职责。也许将基础设施问题（WAP 推送、用户持久性）与域问题（用户注册）分开。这种关注点分离将进一步提高可重用性并提高可维护性。

于 2008-09-26T12:30:24.483 回答