在 MVC 架构中实现服务层答案

【问题标题】：Implementing a service layer in an MVC architecture在 MVC 架构中实现服务层
【发布时间】：2009-08-29 18:31:10
【问题描述】：

通常如何在 MVC 架构中实现服务层？它是为底层业务对象的所有请求提供服务的一个对象吗？或者更像是一个服务于不同服务对象的对象，这些服务对象又与业务对象交互？

所以：

控制器 -> 服务 -> getUserById()，或者：
控制器 -> ServiceManager -> getUserService() -> getUserById()

另外，如果后者更合适，您会在引导程序中配置此 ServiceManager 对象吗？换句话说，在引导程序中向服务管理器注册您的应用所需的不同服务？

如果以上都不合适，什么可以帮助我更好地理解服务层应该如何实现？

提前谢谢你。

【问题讨论】：

标签： model-view-controller service layer

【解决方案1】：

按照我阅读这个问题的方式，确实有两件事需要回答：

A) 我更愿意将“服务”拆分为“客户服务”和“订单服务”，换句话说，按领域概念分组。

B) 其次，我会使用依赖注入直接在我需要的地方获得正确的服务，所以我基本上使用替代 1。替代 2 中添加的抽象对我没有额外的价值，因为 IoC 容器确实重要的部分。

【讨论】：

感谢您的回复 krosenvold。关于您的回答：A）理解并同意 B）我明白您对冗余抽象的看法。但正如我对 Joel 的评论：我很难理解 IoC 将如何在 MVC 环境中实现。这会发生在哪里？在控制器中？这如何提供额外的价值？我认为我不太了解 IoC 的原理，无法掌握它的好处。或者我们是否也在谈论在引导程序中配置它？如果您想详细说明（也许有一个简短的例子），我将非常感激。谢谢。
理解依赖注入的关键概念是，为了有效，它将在大多数地方使用。通常，您将 IoC 容器挂接到非常低的基础设施级别，它会渗透到任何地方。

【解决方案2】：

使用“外观”是一种方法：

"A facade is an object that provides a simplified interface to a larger body of code"

【讨论】：

【解决方案3】：

我个人更喜欢 #2，是的，它通常会在引导程序中进行配置，或者使用某种 IoC 容器来解决依赖关系，从而为您提供实际的具体实例。

我也想发表评论，是的，我明白这可能更多是个人喜好。尽量避免为这些对象使用名称“服务”层。将它们称为存储库或其他东西。如果您使用服务，则该术语会超载……因为那时开发人员就像，“您的意思是像休息还是 wcf 服务？”。相信我，我们在最近的一个项目中做到了这一点，当我们谈论在哪里进行代码更改时，我们总是很困惑：-P

【讨论】：

乔尔，感谢您的回复。我同意您反对将其命名为服务。我只是接受了这一点，但实际上我自己对此有点皱眉。但是层的概念吸引了我。我现在也在尝试掌握依赖注入的整个概念，但我并不完全清楚它是如何工作的。您能否举一个简短的例子来说明这将如何在 MVC 环境中工作？我的意思是，如果在哪里谈论检索用户对象，你会在哪里注入什么？我很难理解这个概念。提前谢谢你。
相信我，当我说我理解你说你正试图围绕 ioc 时。我花了一些时间才弄清楚何时/在哪里使用它 :-) 这个评论框太小而无法真正进入，但我建议查看 ninject lib (ninject.org)。他们的教程逐步完成并开始介绍这些概念。总而言之，这就是将 API 与具体实现分开。您在 mvc 项目中的代码应该针对您的 API 而不是您的特定实现......这样您可以稍后在单元测试时更改它们
根据 Martin Fowler 的说法，服务层“用建立一组可用操作的服务层定义应用程序的边界” 在商业应用程序中，这些操作通常是 CRUD，但并非总是如此。所以我不认为服务层=存储库。真正的服务层（我喜欢的）如何融入 MVC 对我来说仍然是个谜。我的直觉是 MVC 中的 M 应该替换为 S。除非控制器形成我正在谈论的服务层？我想这就是大多数人的做法。但是控制器应该定义应用程序边界吗？我很困惑...
可以有多个边界。我认为这就是你感到困惑的地方。 MVC 应该只关心特定应用程序需要做什么。因此，人们可以看到模型与服务层对话的架构（可能是您提到的 CRUD）。