【发布时间】:2009-05-13 05:05:04
【问题描述】:
我们正在尝试让模型-视图-演示者模式用于(实际上)我们承担的所有新开发工作。
我坚信有一个框架可以帮助人们满足设计要求,我们有一些用于各种不同组件(日志记录、电子邮件发送等)的内部框架,所以我正在尝试获得一些开发的一种 MVP 框架。
我已经设法为不熟悉 MVP 的人提供了一些易于使用的东西,并且与 我们目前的工作方式相差不远。问题在于它正在建立 1 个视图与 1 个演示者的关系。
以下是框架的大致轮廓:
public abstract class Presenter<TView> where TView : IView {
public virtual T View { get; set; }
public virtual void Setup(TView view) {
this.View = view;
}
}
public interface IView { }
它的基本工作方式是任何创建的 View 都继承自 IView 接口,并传递给继承自 Presenter 抽象的 Presenter 类类。
如您所见,我正在使用 .NET 泛型,以便开发人员在使用 Presenter(然后最终是从 Presenter 继承的类)时对 View 进行强类型化。
所以我可以像这样设置一个基本的登录组件:
public class Login : Presenter<ILogin> {
public override Setup(ILogin view){
base.Setup(view);
this.View.Login += new EventHandler(login);
}
void login(object sender, EventArgs e) { ... }
}
public interface ILogin : IView {
string Username { get; set; }
string Password { get; set; }
event EventHandler Login;
}
所以正如我所说的,我非常喜欢这个,有编译器强制类型、强类型视图和 MVP-like 模式。
尽管有些人对实现不太满意,因为它在演示者和视图之间具有一对一的关系,严格来说这不是 MVP 的本意。
我质疑这个论点的有效性,在我一直在跟踪这个框架的几个项目中(从大中型项目)我没有找到任何好的例子,我认为“我需要有多个视图这位主持人”。当我看到可以在多个视图之间共享的功能时,我会质疑它是否应该与特定的演示者相关联,或者是否应该在一个更中立的类中。
我试图实现的框架是否离 MVP 太远而不能被称为 MVP? MVP 的主要目标是需要对演示者有多个视图吗?是否有可能拥有一个真正支持 n-view 的 .NET MVP 框架?
【问题讨论】: