我用MVP模式创建了一个论坛系统,但我不确定我是否以正确的方式实现了它。所以这就是我最终的结果:
在模型类中我只调用类型化数据集方法,在演示者中我称之为模型方法。视图为.aspx
页面。这就是论坛系统的全部内容,但这里有一个棘手的部分:
由于MVP模式是一种UI模式,我必须在Application本身中进行数据验证。所以我的设计MVP就是应用程序!
我做错了什么?
编辑1:首先关于为什么我选择带有存储过程的类型化数据集而不是其他选项:它是最轻的数据提供商,它不会影响您拥有的任何架构。其他选项是直接sql,这对于新创建的应用程序来说不是一个好选择,LINQ到sql类太重了,无法用每个请求实例化,实体框架很棒,但对于这么简单的任务来说太多了!至少如果我正在创建一个博客引擎,它将是我的第一选择。 至于为什么我没有选择MVC,这是因为我认为MVP是更好的模式,因为它会给我完全分离我的应用程序的不同部分。最后这是一个问题,但你应该能够实现任何模式,对吧? 我见过不同风格的MVP,但我试图实现的是:
model<------------->presenter<-------------->view
数据绑定选项是针对演示模型模式,据我所知,由马丁·福勒引入,但我正在尝试创建的是微软版本,它基本上是PM模式的扩展版本。
两天前我问了一个关于数据验证的问题,有人建议我应该在“应用程序本身”中这样做,所以当我问这个“应用程序”在哪里时,他说MVP是一个UI模式,它不应该作为您的“应用程序”,您应该在用户界面层中实现MVP。所以这就是我在第一时间问这个问题的原因!
答案 0 :(得分:2)
使用MVP后面的代码成为基于View界面的View实现。
View接口包含Presenter需要绑定的页面事件,以便更改View的状态,以及它可能需要的属性和方法。例如,它可以挂钩onLoad事件并调用View来改变它的状态。在这样做时,它与View实现无关,对控件一无所知。这意味着您可以在没有ASPX实例的情况下编写单元测试。
要创建一个自动化连线的MVP引擎,您可以使用基页,泛型和IoC。 IoC允许您为WebContextBase设置依赖性覆盖,WebContextBase仅对该请求管道可见,并且可以传递给Presenter构造函数。
IoC还允许您将其他依赖项注入到Presenter中以帮助保持其轻量级。这样,您就可以将业务和数据访问权移动到其他层。
MVP在 使用WebForms(例如大多数CMS系统)时非常有用。如果您没有受到限制,那么请使用MVC.Net进行新的Web开发。
更新:正如所承诺的那样,decent example是公平的。它缺少的是依赖性覆盖,可以这样做:
var dependencies = new DependencyOverrides
{
{typeof (HttpRequestBase),new HttpRequestWrapper(Request)},
{typeof (HttpResponseBase),new HttpResponseWrapper(Response)},
{typeof (IPrincipal),Context.User},
{typeof (IIdentity),Context.User.Identity},
{typeof (IUserProfile),Context.User.Profile},
{typeof (HttpSessionStateBase),new HttpSessionStateWrapper(Session)}
};
presenter = container.Resolve<TPresenter>(dependencies);
答案 1 :(得分:0)
通过在ASP.NET MVC框架上选择webforms,您犯了一个架构错误。类型化的数据集也是如此,你应该使用Entity Framework。与时俱进!
答案 2 :(得分:0)
你看过ASP.NET MVC了吗?它是模型 - 视图 - 控制器模式,将为您处理所有路由和管道。您可以使用DataAnnotations轻松验证模型,并且有大量Resources和Tutorials
或者是否有特定原因需要将MVP模式与经典ASP.NET一起使用?
答案 3 :(得分:0)
由于你的问题不是关于MVC与MVP或Typed Dataset vs Entity Framework的优点,我假设你有一个令人信服的理由按照你的方式做事。
有了这个,你似乎没有做错任何事。使用MVP,验证应该在Presenter实现中进行,因为它们可以在回发期间访问您的视图实例。当然,您也可以使用javascript进行客户端验证。