2010-11-08 95 views
2

这是一个ASP.NET MVC网站。可以从另一个应用程序服务中调用一个应用程序服务吗?

以下领域驱动设计,我们有一个服务层。我们的控制器要求应用程序服务类执行各种任务,然后将结果发送到视图。

业务逻辑由服务类执行。

因此,例如,我可能有一个AccountTasks类,它负责注册用户,编辑他们的偏好等。现在,我需要能够在注册后立即自动订阅用户,或者更新他们的用户偏好(然后我会更改新闻订阅)。

新闻订阅功能因此与帐户注册/修改密切相关。

但是,我觉得最好有一个单独的NewsletterTasks服务类来处理订阅/更新/取消订阅操作。

但是这个类不会被控制器使用,而是AccountTasks类。

因此,工作流会是这样:

-> request made to controller action 

-> controller calls AccountTasks 

-> AccountTasks creates a user acoount 

-> AccountTasks calls NewsletterTasks 

-> NewsletterTasks subscribes the user to the newsletter 

-> AccountTasks returns the result to the controller 

-> controller fetches the appropriate view and sends it to the client 

或者,我会控制调用AccountTasks第一,然后使用结果调用NewsletterTasks。但是通过这种方法,我觉得控制器对工作流程知之甚多,而应该只是传递数据和结果。

任务是应用程序服务类,该项目基于S#arp架构,其中一些修改来自Who Can Help Me - 其中包括某些事情的命名约定。

可以从AccountTasks拨打NewsletterTasks吗?你会如何做到这一点?

回答

3

我很想创建一个明确的放在userRegistration域名服务

-> request made to controller action 

-> controller calls UserRegistrationService 

-> UserRegistrationService calls AccountTasks 

-> AccountTasks creates a user acoount 

-> UserRegistrationService calls NewsletterTasks 

-> NewsletterTasks subscribes the user to the newsletter 

-> UserRegistrationService returns the result to the controller 

-> controller fetches the appropriate view and sends it to the client 

这反过来又回答您的问题:是的,它确认从服务

调用其他服务

希望有所帮助!

+0

但是,如果我没有引入域服务,那么如果AccountTasks调用NewsletterTasks(并且具有依赖关系,我们使用DI),您认为它还可以吗?下面的Szymon说他只是把它放在控制器中,但是如果可以的话,我会尽量让我的控制器哑巴,并将任何业务逻辑委派给服务类。虽然我不愿意再添加一层,但这整个架构对我来说已经是一个巨大的飞跃。 :) – 2010-11-09 10:21:19

+0

我倾向于同意 - 保持控制者'愚蠢'更加符合DDD。我将介绍** UserRegistrationService **的原因是使域操作*显式*。但是,如果你的团队说,打电话给AccountTasks-> NewsLetterTasks感觉更自然,那么就去做吧。 DDD是让事情变得更容易理解,而且更容易改变。 – 2010-11-09 10:40:45

-1

我会主张控制器调用这两个任务的设计。是的,它给控制器增加了额外的责任,但另一方面,它消除了AccountTasks调用NewsletterTasks有点尴尬的责任。其他人应该决定是否为某个特定帐户订阅新闻通讯(事件目前是所有用户都订阅)。

我会这样做的务实:只有2个任务,我会把定义工作流程的责任(可能在一个单独的方法)。随着任务数量的增长,我将定义一组特殊的类,其唯一目的是定义工作流。

您的设计看起来与Juval Lowy的“The Method”有些相似,您的任务与他的经理有点相似,因此您可以看看他的paper

相关问题