服务层相互依赖答案

【问题标题】：Service layer interdependency服务层相互依赖
【发布时间】：2010-11-12 12:33:16
【问题描述】：

我正在设计一个使用服务层的 asp.net mvc 应用程序。如果我们有一个依赖于另一个服务的服务怎么办？例如，假设我们有以下模型：

class UserService : IUserService
{
    //implementation requires IEmailService
}

当然，EmailService 的具体实现可以注入到 UserService 的构造函数中，但是在我的理解中，服务层应该是 UI 和 Domain Model 之间的中介，它就像一个门面。我会以这样一种方式定义另一个层，即 UserService 依赖于 IUserModule 和 IEmailModule，这样我们就可以打破服务之间的依赖关系，服务依赖于较低的层（在我的例子中是模块层）。这是一个正确的方法吗？

【问题讨论】：

标签： asp.net-mvc

【解决方案1】：

在一个常见的 DDD 架构中，您会发现两种服务域服务（协调实体之间的业务操作）和应用程序服务（它们依赖于域服务，并且包含与应用程序相关的任务，而不是与业务逻辑相关的任务）例如，导出为 pdf 是一项应用程序任务。应用折扣是一项业务逻辑任务）。

因此，如果您只有一种服务，我想它涵盖了两种职责。具有相互依赖关系是完全有效的。

【讨论】：

【解决方案2】：

当然，EmailService的具体实现可以注入到构造函数中 UserService，但在我的理解中，服务层应该在 UI 和 Domain 之间进行调解型号

嗯，这是双方之间的合同，不一定是 UI 和领域模型，但通常是这样。

它就像一个门面。

是的，良好的服务具有漂亮的外观，同时也考虑了性能。

这样我们可以打破服务之间的依赖关系，服务依赖于一个下层（在我的例子中是模块层）。这是一个正确的方法吗？

模块对您意味着什么？ IEmailService 对您来说是服务还是模块？在您的情况下为您的服务创建外观似乎是正确的。但是您提供的关于您的系统、您的意图以及您的架构挑战/优先级的信息很少。

【讨论】：

Falcon，该模块包含业务规则和与repository层的交互。

【解决方案3】：

您应该避免依赖注入，因为它会增加耦合性和复杂性，从而产生一种灵活性的错觉。在开始开发之前，MVC 也是需要重新考虑的东西，因为除了执行 CRUD 操作的简单应用程序之外，它对其他任何东西都没有好处。 Web Forms 是一个更成熟的平台，更适合更多可用的应用程序。

【讨论】：

“依赖注入是你应该避免的，因为它会增加耦合和复杂性，从而产生一种灵活性的错觉。”什么？
米奇，你知道什么是依赖注入或MVC以及如何使用它吗？
-1：在建议“避免”某事之前先做一些研究。你的回答与现实180度角。
我猜这取决于个人的经验，但我觉得 MVC 是为 Web 而不是 Web 表单编程的正确方法！ :)
@Mitch：你有很多东西要学。软件开发中的任何工具的好坏取决于上下文。依赖注入对于大型复杂系统非常有用，但对于“Hello, world”应用程序来说却很糟糕。 MVC 不仅仅适用于 CRUD 应用程序；但对于没有长期维护考虑的快速而肮脏的小型项目来说并不是那么好。