WinForms 的服务容器或 IoC 建议

发布于 2024-10-30 12:07:11 字数 682 浏览 2 评论 0原文

我正在 WinForms 中编写一个应用程序,想知道是使用 IoC 还是容器。

我们正在编写的是一个文本编辑器,用于我们自己开发的 BASIC 风格语言,用于计算费用等。它类似于 Notepad++,但没有那么多功能和调试器。

我想知道我是否应该使用容器或 IoC,以及我应该选择哪一个。作为一个 WinForms 应用程序,在启动时必须做很多事情(加载语法引擎、UI 配置等),您认为我什至可以使用 IoC 吗?

使用容器,我可以将其设为静态类,然后执行 Container.GetInstance(),但是当某些类依赖于其他类等时,我看不出如何连接 IoC。

我还有很多命令我想使用 COMmand 模式,因此定义一个 ICommand 并针对特定区域使用 ITextCommand、IFormulaCalculationCommand、IDebugCommand 进行扩展。我什至如何使用 IoC 来表示从这些命令之一获取选项卡中的活动文档?

现在这一切让我感到非常困惑,我深表歉意。

如果您不能清楚地回答上述问题,这里有几个简短的问题:)

  • 什么是最快和最简单的容器(ServiceContainer?)
  • 您会为这个 Windows 窗体项目推荐一个像 Autofac 这样的 IoC 吗?
  • 您可以实现 IoC 并仍然使用命令模式来调用命令并获取正在编辑的活动文档等吗?

I'm writing an application in WinForms and wondered whether to use an IoC or a Container.

What we're writing is a text-editor for our home grown BASIC style language for calculating fees etc. Its something like Notepad++ but not as much functionality and a debugger.

I'm wondering whether I should be using a Container or an IoC and which I should opt for. Being a WinForms application and having to do quite a few things at startup (Loading syntax engine, UI configuration etc) do you think I can even use an IoC?

With a container, I can make it a static class and just do Container.GetInstance() but I can't see how one could wire up an IoC when some classes will depend on others etc.

I also have quite a number of commands that I want to use the COmmand Pattern for, so define an ICommand and extend with ITextCommand, IFormulaCalculationCommand, IDebugCommand for specific areas. How would I even use IoC to say get the active document within a Tab from one of those commands?

Its all very confusing to me right now and I apologise.

Here's a few short questions if you can't answer the above cleanly :)

  • What's the fastest and simplest Container (ServiceContainer?)
  • Would you recommend an IoC like Autofac for this Windows Forms project?
  • Can you implement IoC and still use the command pattern to invoke commands and get teh active document being edited etc?

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

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

发布评论

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

评论(1

迷途知返 2024-11-06 12:07:11

首先,“IoC”的意思是“控制反转”,它是一个依赖注入高度相关的概念(不是具体的软件组件) a>。 容器软件组件)是依赖注入容器。所以“IoC”和“容器”不仅是两个无法比较的实体,而且可以说它们属于同一个“阵营”。

因此,这个问题最好表述为“我应该为我的应用程序使用 DI 容器吗?”。

您可以选择多种 DI 容器:Microsoft Unity、Castle Windsor 和 NInject 是其中一些较知名的容器(直到现在我才知道 Autofac)。选择一个并继续;您的情况不会有任何实际差异,如果需要,您可以随时相对轻松地切换到另一种情况。

此外,容器的一个主要卖点是,您不需要将它们连接起来以构造具有深度依赖树的类。容器自动解析并注入依赖项;仅当您需要使用传递给构造函数的特定值来进行对象构造时,您才需要提供帮助。

最后,DI 容器和命令模式或类似的东西之间没有任何关系。如果您想获取活动文档,只需在活动文档发生更改时将其内容存储在变量中,并在需要时读取该变量即可。容器根本不进入其中。

更新:添加指向高度相关问题的链接哪些 .NET 依赖注入框架值得研究?

First of all, "IoC" means "inversion of control" and it is a concept (not a concrete software component) that is highly related to dependency injection. The container (which is a software component) is a dependency injection container. So not only are "IoC" and "container" two entities that cannot be compared, they are also inside the same "camp" so to speak.

Therefore the question could better be phrased as "should I use a DI container for my application?".

There are several DI containers you can choose from: Microsoft Unity, Castle Windsor and NInject are a few of the more well-known ones (I was unaware of Autofac until now). Pick one and go ahead with it; there will be no practical difference in your case and you can always switch relatively easily to another one if the need arises.

Further, a major selling point of containers is that you do not need to wire them up to construct classes with deep dependency trees. The container resolves and injects the dependencies automatically; you only need to help if you need object construction to happen with specific values passed to a constructor.

Finally, there is no relation between a DI container and the command pattern or anything like that. If you want to get the active document, then simply store what the active document is in a variable whenever it changes and read that variable when you need. The container does not come into it at all.

Update: Adding a link to the highly relevant question Which .NET Dependency Injection frameworks are worth looking into?

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