经理班

在我最近完成的一个项目中,我们使用了一个体系结构,因为它的Web /服务层的顶层交互使用了XXXManager类.

例如,有一个按计划运行的Windows服务,它将来自多个不同数据源的数据导入我们的系统.在此服务中,调用了几个"Manager"类,即CPImportScheduleManager,CPImportProcessManager等.

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

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

我从来都不是解释自己的最佳人选,但如果我的谣言有意义,请随时提出建议.

干杯,克里斯.

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

我会遇到的重要问题是经理们面前发生了什么？如果它们简单地协调过程的工作流程,例如注册用户,那么它们是具有不同名称的控制器(MVC).但是,如果它们包含许多业务逻辑(我的意思是条件逻辑取决于实体或实体集的状态)那么我会仔细看看是否可以通过使其成为拥有自己的班级,或者以适当的责任将其移到班上.

更新:从它的声音来看,你一般都有正确的想法.您有一组用于处理业务流程协调的类,这些类不关心WebService,Webform或其他任何内容是否正在使用它们.然后,您要说的是要在此基础上添加WebService层并使用这些类.这是一件好事(tm).