【问题标题】:Dependency Injection Implementation依赖注入实现
【发布时间】:2014-07-10 01:49:10
【问题描述】:

我的解决方案中有三层,Presentation(winforms 项目)、Domain(类库)和 Persistence(类库)。 我正在尝试实现依赖注入来解耦它们。 我的应用程序根在我的表示层中。 我知道唯一一次应该引用 DI 容器(在这种情况下为统一)是在我的应用程序根目录中,否则我将简单地用对我的 DI 容器的依赖项替换整个地方的类依赖项(我想这仍然稍微好一点)。

因此,考虑到这些基础概念,我真的在为具体的实现而苦苦挣扎。也许我的应用程序根目录应该在它自己的单独项目中——也许是一个控制台应用程序。然后我可以解析第一个“overallApplication”类,在其构造函数中列出 IPresentation、IDomain 和 IPersistence。我了解(假设已注册实际实现)统一框架将递归地解决所有相应的子依赖项。

根据您的经验,您能否建议这是否是一种合理的方法。我真的了解解耦的概念和重要性,以及如何通过 DI 从概念上在高层次上解决这个问题,但我正在努力将它们结合在一个具有多层的实际应用程序解决方案中(在 VS 中作为单独的项目组织)。

非常感谢任何有关正确实现示例的帮助或指针。

【问题讨论】:

标签: c# architecture dependency-injection


【解决方案1】:

一些想法,希望对你有所帮助。

在你的问题中,你会做出如下陈述:

“我非常了解解耦的概念和重要性,以及 DI 是如何解决这个问题的……”

我要评估的第一件事是理解 DI != IoC Container(例如 Unity)。

IoC 容器用于删除由现有 DI 结构产生的样板代码。因此,我建议您在没有 Unity /first/ 的情况下进行重构。然后回去添加Unity来减少你的代码。

这样:
-1。通过手动Ctor、Property、Method、Service Locator注入方法制作应用Di。
-2。设置完成后,您应该会看到如下内容:

public View() {
  var controller = new Controller(new IView(), new model(), new IService(new Dal(ISession(connectionString))), new , new ILogger(), etc.){}
}

-3。然后,一旦您的代码中有这样的内容,您就可以使用 Unity 注入所有这些乐趣:

public View() {}
Controller Controller {get;set;}  //<- Unity auto builds & populates this for you with all the "new" items normally found in your constructor (or wherever).

虽然不是生产示例,但它应该提供一些重构步骤的想法。可以这么说,直接使用 Unity 会本末倒置。

【讨论】:

  • 当我说“我真的明白”时,我有一种感觉我是敞开心扉的 :) 好的,谢谢,了解依赖注入和 IoC 容器之间的区别很有用。
  • 请注意,Service Locator 是最后的手段 - 您最多只能将多个依赖项减少到一个。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-01-03
  • 2023-03-14
  • 2014-01-08
  • 2016-11-08
  • 1970-01-01
  • 1970-01-01
  • 2017-03-11
相关资源
最近更新 更多