1

我正在处理 DotNetNuke 模块中的遗留代码，试图在测试框架下获取类和行为：我借此机会遵循“有效使用遗留代码”一书中的建议，所以发生的事情是我m 试图定义可以彻底测试然后转换为服务的区域。然后我想使用一个 IoC 框架来工作。目前，我已经将目光投向了 Ninject。

但是我遇到了一个设计问题：因为我在 DotNetNuke 模块中，所以我无法真正更改应用程序范围的结构：例如，我无法从 NinjectHttpApplication 派生应用程序。我也不能使用来自 SO 的这些建议。我正在考虑将内核放在我的模块将设置然后使用的静态类中，但从我所阅读的内容来看，这是一个非常糟糕的主意。

所以我开始问自己是否可以在尚未设置为从头开始支持它的应用程序中使用 IoC。如果我应该为每个请求加载一个完整的依赖树，我如何在本地重写遗留代码并从 IoC 中受益？是否有一种模式可以使 IoC 的使用可以从非常本地的重写中发展出来？

即使我正在使用 DotNetNuke，任何可以安装到独立框架中的独立组件都会引发同样的问题。我也没有专门针对 Ninject，如果另一个 IoC 框架可以在这种情况下提供帮助，我愿意考虑。

4

1 回答 1

2

根据我的经验，在 DotNetNuke 的上下文中获得这种抽象类型的最佳选择是使用 WebFormsMVP 框架。这确实是我发现在 DNN 模块中进行单元测试的唯一明智的方法，如果没记错的话，我大约一年前花了一段时间尝试连接 Ninject。

但请注意，它仍然是 WebForms，永远不会变得简单。在不了解您现有的代码库的情况下，我很难知道进行迁移有多么容易。

我在 GitHub 上有一些资源，您可以查看以供参考：

第一个是一个模块模板，应该作为一个坚实的起点：

https://github.com/irobinson/WebFormsMvp-DNN-Module-Template

第二个是一个小示例项目：

https://github.com/irobinson/BeerCollectionMVP

根据您使用的 DNN 版本，它可能已经或可能尚未随 WebFormsMVP 提供，但您应该能够将依赖项与您的模块捆绑在一起，或者在合理的情况下升级到较新版本的 DNN。

于 2012-12-18T16:32:31.597 回答