解耦视图，演示文稿和ASP.NET Web窗体
我有一个ASP.NET Web窗体页面，演示者需要在其中填充控件。 这种交互对页面生命周期有点敏感，我想知道是否有一个技巧，我不知道。
我想要对整个事情保持实用，但不要牺牲可测试性。
目前我有这个：
public interface ISomeContract { void InstantiateIn(System.Web.UI.Control container); } 这个契约依赖于System.Web.UI.Control，我需要能够使用ASP.NET Web Forms编程模型。 但是视图和演示者都不了解ASP.NET服务器控件。
我该如何解决这个问题？ 如何在我的具体视图中使用ASP.NET Web窗体编程模型而不在合同程序集中使用System.Web.UI.Control依赖项？
为了澄清一点，这种类型的界面都是关于UI组合（使用MEF）。 它在整个框架中是众所周知的，但它实际上只是在具体视图中调用。 具体视图仍然是唯一知道ASP.NET Web窗体的东西。 但是，那些说InstantiateIn(System.Web.UI.Control)公共方法存在于我的合同程序集中，这意味着对ASP.NET Web窗体的依赖。
我一直在考虑一些双重调度机制甚至访问者模式来尝试解决这个问题，但我还不知道我想去哪个方向，我真的希望对此事有一些意见。
不确定访问者如何解决问题。 但为什么不让你的合同看起来像这样：
public interface ISomeContract { void InstantiateIn(IControl container); }
使用IControl实现，可能在另一个程序集中保持合同程序集清洁，包装ASP.NET System.Web.Control，如：
public class AspnetControl : IControl { public AspnetControl(System.Web.Control control) { } // IControl members that dispatch to control }
虽然最终IControl很可能最终看起来非常像System.Web.Control（因此在一开始就摒弃了它的抽象点），但它仍然是非常可测试的，你的观点和主持人赢了不得不知道关于ASP.NET的事情。
将协议与Web控件分离的一种方法是让一个单独的编写器处理从ISomeContract获取信息并将其放在Control容器中。 这可以驻留在引用契约程序集和System.Web的程序集中。
我一直在阅读有关敏捷技术，tdd，unit testing，可靠，设计模式的内容，并且感觉完全没有能力弥合从所有这些精彩理论到asp.net webforms的差距。
我今天早些时候又试图找到解决这个问题的方法，并发现了这篇文章：
这是我认为可以解决我所有问题的一本书的摘录，但本章实际上只是对在webforms中实现MVP模式的可能性的介绍，最后说它不是真正实用的。 本书的其余部分是关于我收集的测试asp.net MVC。
还有这个新项目旨在将爱带回到webforms平台：
在“普通”ASP.NET Web表单中，您的页面/用户控件在技术上“负责”处理，并在代码上强加其生命周期。 无论您喜不喜欢，该页面都是Presenter和View。
在这种环境中实施MVP模式的大多数尝试只会给已经过于复杂的环境增加过多的复杂性！ 假装另一个类是Presenter就是……假装。 （在MVC网站中，Controller确实控制代码，View不支持，因此该参数不再适用。）
我的建议是让视图管理自己的生命周期，并让它调用Repositories和Model类来检索/保存数据并调用命令。
在这种方法中，Model类不需要了解System.Web的任何信息。 然后，这些相同的Model类可以在未来的MVC网站或Silverlight中使用，或者作为WPF应用程序的Web服务使用，或者嵌入到WPF应用程序中，等等。由View决定如何实现（使用Controls）它从模型中获得的响应/数据。
如果正确设置模型类以支持dependency injection，则可以根据需要测试模型类。
希望有所帮助！