解耦视图、表示和 ASP.NET Web 窗体

发布于 2024-08-27 12:40:08 字数 714 浏览 11 评论 0原文

我有一个 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 Forms 编程模型，而不在合同程序集中采用 System.Web.UI.Control 依赖项？

为了澄清一点，这种类型的界面都是关于 UI 组合（使用 MEF）的。它在整个框架中都是已知的，但实际上只是从具体视图中调用。具体的视图仍然是对 ASP.NET Web Forms 唯一了解的东西。然而，那些表示 InstantiateIn(System.Web.UI.Control) 的公共方法存在于我的合约程序集中，这意味着对 ASP.NET Web 窗体的依赖。

我一直在考虑一些双重调度机制甚至访问者模式来尝试解决这个问题，但我还不知道我想要朝哪个方向发展，我真的很希望对此事有一些意见。

原文

I have an ASP.NET Web Forms page which the presenter needs to populate with controls. This interaction is somewhat sensitive to the page-life cycle and I was wondering if there's a trick to it, that I don't know about.

I wanna be practical about the whole thing but not compromise testability.

Currently I have this:

public interface ISomeContract
{
    void InstantiateIn(System.Web.UI.Control container); 
}

This contract has a dependency on System.Web.UI.Control and I need that to be able to do things with the ASP.NET Web Forms programming model. But neither the view nor the presenter may have knowledge about ASP.NET server controls.

How do I get around this? How can I work with the ASP.NET Web Forms programming model in my concrete views without taking a System.Web.UI.Control dependency in my contract assemblies?

To clarify things a bit, this type of interface is all about UI composition (using MEF). It's known through-out the framework but it's really only called from within the concrete view. The concrete view is still the only thing that knows about ASP.NET Web Forms. However those public methods that say InstantiateIn(System.Web.UI.Control) exists in my contract assemblies and that implies a dependency on ASP.NET Web Forms.

I've been thinking about some double dispatch mechanism or even visitor pattern to try and work around this but I don't yet know in which direction I want to go and I would really like some input on the matter.

分享到QQ

分享到微博

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

发布评论

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

稚气少女 2024-09-03 12:40:08

不知道访客会如何解决这个问题。但是为什么不让您的合同看起来像这样：

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 。网。

Not sure how a visitor would solve the problem. But why not have your contracts look like this:

public interface ISomeContract
{
    void InstantiateIn(IControl container); 
}

with an IControl implementation, possibly in another assembly to keep your contract assembly clean, that wraps over the ASP.NET System.Web.Control, like:

public class AspnetControl : IControl
{
    public AspnetControl(System.Web.Control control) { }

    // IControl members that dispatch to control
}

Although there's a high likelihood that eventually IControl would end up looking very much like a System.Web.Control (and hence defeat the point of abstracting it in the first place), it'd still be very testable, and your view and presenters won't have to know a thing about ASP.NET.

回复收藏 0 原文