与使用我构建的容器相比,使用第三方依赖注入容器有什么好处?

发布于 2024-10-03 23:23:11 字数 476 浏览 3 评论 0原文

我很久以前在观看这个节目时构建了一个 IoC 容器 http://www.dnrtv.com /default.aspx?showNum=126 几个月前,并使用它做了一个小样本,并且工作正常。

现在我在我正在启动的项目中使用 unity 作为依赖项注入容器,并且还尝试了 NInject 在以前的小型 MVC 网站中。

但我现在问自己,这些容器比我在节目中创建的容器有什么好处,我只是可以看到它从配置文件加载,我可以在我的文件中执行此操作,还有其他我缺少的东西吗?我只是想让有人告诉我你必须使用这些容器,因为 1、2、3 个原因比你的更好。

I Built an IoC container long time ago while watching this show http://www.dnrtv.com/default.aspx?showNum=126 few months ago, and did a small sample using it, and was working fine.

Now I am using unity as a dependency injection container in a project I am starting, and also tried NInject in a previous small MVC website.

But I am now asking my self, what these containers benefits over the one I created from the show, I just can see that it load from the config file, which I can do in mine, is there something else I am missing? I just want some one to tell me you must use these containers because of 1, 2 , 3 reasons which is better than yours.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

莫相离 2024-10-10 23:23:11

首先,这些容器被广泛使用,因此在现实世界中经过了充分的测试 - 我不知道你的情况如何。

它们也有很好的文档记录,并且为许多开发人员所熟悉,因此如果在团队中工作,则无需向其他人传授您的知识。

一些容器提供流畅的配置(即代码中的配置),这为您提供了编译时与运行时的类型安全性。

但是,如果您的容器适合您并且没有其他开发人员参与,为什么要改变呢?

First off, these containers are widely used, hence well tested in real world situations - I don't know about yours.

They are also well documented and familiar to many developers, so if working in a team, there is no need to teach others about yours.

Some containers offer fluent configuration (that is, configuration in code), this gives you type safety during compile time vs run time.

However, if your container works for you and there are no other developers involved, why change?

掩饰不了的爱 2024-10-10 23:23:11

其他 IoC 容器将:

  • 更成熟,并且很可能出现更少的错误
  • 具有更好的性能
  • 由其他人维护
  • 具有比您最初想象的更多的功能,覆盖更多的场景
  • 与其他开箱即用的框架(例如 MVC、WCF 等)集成)
  • 有一个社区来讨论这些问题以及如何解决这些问题

,而如果使用您自己的社区,您会远远落后,并且不会得到上述所有事情的支持。

如果您的目标是构建一些能够与已有的产品(例如 Autofac、Ninject、Unity 等)竞争的产品,那么请将其作为您的产品。

Other IoC containers would:

  • be more mature and most probably less buggy
  • have better performance
  • be maintained by someone else
  • have more features covering more scenarios than you would originally think of
  • have integration with other frameworks out of the box (such as MVC, WCF, etc)
  • have a community discussing the problems and how to get around them

With your own, you'd be a LONG way behind, and wouldn't have the support of all the things mentioned above.

If you're aiming to build something that competes with the players already out there (such as Autofac, Ninject, Unity, etc) then make that your product.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文