mvp | 易学教程

MVP events or property

阅读更多关于 MVP events or property

问题 I'm using the MVP pattern in a windows form app. I need to change a radio button on the view. I can do this by exposing a Boolean property on the view, but should I be using events to manipulate the view instead? 回答1: It's a matter of purity vs being pragmatic... and a bit of personal style. Shouldn't matter... events are just more work than normal methods but more decoupled. Personally I like to keep views decoupled or unaware of the presenters, hence Views communicate to the presenter by

GWT servlet filter ,How to identify special service request?

阅读更多关于 GWT servlet filter ,How to identify special service request?

问题 I created a app with GWT+requestfacotry(MVP)+GAE. There are some service or method exposed to GWT client ,such as 1.create 2.remove 3.query I want to add authorization function to "create" and "remove" ,but not to "query". I did it with servlet filter : public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { UserService userService = UserServiceFactory.getUserService(); HttpServletRequest request =

Register a Presenter with a View

阅读更多关于 Register a Presenter with a View

If I have a presenter like this - public class LandingPresenter : ILandingPresenter { private ILandingView _view { get; set; } private IProductService _productService { get; set; } public LandingPresenter(ILandingView view, IProductService) { .... } } How do I register this Presenter with Autofac considering the dependent view will not be registered (but IProductService will) builder.RegisterType<LandingPresenter>().As<ILandingPresenter>(); ???? Why not register the views in the container as well, put Autofac to work! Then you can hook up presenters and views automagically by using constructor

Android中MVP模式

阅读更多关于 Android中MVP模式

MVP是MVC的衍生版本，跟MVC类似，但是在Android中更适用，也分三层： Model：用于数据的增删改查等，也包括一些数据对象 View：用于界面的显示与用户操作的接收，在Android里面View通常就是Actvitiy，Fragment。 Presenter：是View跟Model的“中间人”，接收View的请求后，从Model获取数据交给View。 MVP&MVC的区别传统MVC有着悠久的历史，但是Android却选用MVP，这绝非偶然。在MVC中： M：解决用什么去渲染 V：解决怎么去渲染 C：解决用户输入事件在Android中，假如使用MVC，代表V的layout资源并不能完全解决怎么去渲染的问题，还需要Activity的辅助，所以Activity也必然要代表V；但是同时，Activity一方面拥有生命周期回调，另外一方面还为View设置监听，Activity接收来自用户的输入，所以Activity也必然也代表C，Activity就像一个万能对象同时代表着V与C。因此，使用MVC并不能很好地将V与C分离开来。与MVC不同的是，MVP中的View是可以接收用户输入，同时也能解决怎么去渲染的问题，所以Activity可以作为MVP里面的View，但是却做不了MVC里面的View。因此，MVP更适用于Android。但是View的改变不只在此

《android-MVP模式的困惑》

阅读更多关于《android-MVP模式的困惑》

什么是MVP模式呢？我的理解就是老的MVC架构模式的一种延伸，能体现一种面向接口编程的思想。之所以会有MVP，是因为MVC中，C即Controllor对应于Activity或者Fragment。他们负责的东西太多了。比如：控件的初始化，网络请求，数据绑定，事件传递等。这显得我们的Controllor太过于臃肿(即又当C又当V)。而为了给Controllor减轻负担，于是就有了Presenter这个一个中间层，让Presenter负责完成View于Model间的交互。这有点像Web开发中的Service，什么业务逻辑都放在这里来处理，然后再与Action交互。在网上也看到了很多图形来解释MVP与MVC的区别,如下: 这是mvc：这是MVP：主要区别是这样的：还有就是真个项目的结构图：通过上面的几个图我们不难发现，MVP模式中Presenter在这整个模式中显得很重要，那么问题来了(这也是我没用想明白的事情)： 1、Presenter通过接口的方式提高了代码的复用性，降低了耦合度，但是如果业务非常复杂的时候Presenter层会不会也会像MVC模式中的Activity一样显得很臃肿。 2、Presenter既然负责完成View于Model间的交互，那么它的生命周期怎么去控制。 3、Presenter层的出现，虽然降低了耦合度，但是相对于MVC来说代码量会增加部分

Models, Views, View Models and Presenters

阅读更多关于 Models, Views, View Models and Presenters

I'm trying to get to grips with different patterns (MVP, MVVM etc) and find one that suits my needs. After all my reading I'm still not sure. Hopefully someone can shed some light on this for me. At the moment I have a WPF View which implements an interface ICustomView. This interface is injected into my Presenter. The presenter then is responsible for subscribing to data, managing subscriptions etc. When the data is returned to the Presenter it calls various methods against the Model (an IObservable collection of CustomBusinessObjects). It does this using the interface ICustomView since the

Wiring View, Model and Presenter dynamically, by convention / reflection

阅读更多关于 Wiring View, Model and Presenter dynamically, by convention / reflection

I'm trying to develop an application using the MVP pattern. The problem is wiring all the code manually. I was hoping to reduce the code needed. I tried to copy another solution, but I couldn't get to work. I'm using Winforms and the solution I was using as source is using WPF. It would wire things on some conventions: View events are wired by name. For example:"Loaded" event on the view will be wired to the "OnLoaded()" method on the presenter Button commands are wired by name. For example: MoveNext" button is wired to the "OnMoveNext()" method. Grids double click is wired by name. For

In MVP, who should handle navigation?

阅读更多关于 In MVP, who should handle navigation?

问题 It's my belief that the Presenter is the one responsible for handling the navigation aspect of a MVP application. Is this true or are there exceptions? 回答1: You are right. The model cannot do it, and the view cannot do it. In my apps, navigation is handled by cascading from the largest presenters to the smaller ones. For instance the overall app presenter gets the whole location, parses it, and sends any relevant pieces to the next presenter for finer-grained detail. 回答2: I think the view is

Improving MVP in Scala

阅读更多关于 Improving MVP in Scala

问题 The classical strongly typed MVP pattern looks like this in Scala: trait IView { } trait Presenter[View <: IView] { // or have it as an abstract type member val view : View } case class View1(...) extends IView { ... } case object Presenter1 extends Presenter[View1] { val view = View1(...) } Now, I wonder if there is any nice way to improve on it which I am missing... 回答1: Nice thing about MVP pattern is that it makes your UI code unit testable. I'd suggest you to avoid instantiating view in

Applying Dependency Injection on an ASP.NET web forms application built using MVP Pattern

阅读更多关于 Applying Dependency Injection on an ASP.NET web forms application built using MVP Pattern

I am creating an ASP.NET Web forms application with MVP pattern. The structure of my view is something like this: public partial class ShipperView : System.Web.UI.Page, IShipperView { ShipperPresenter presenter; public ShipperOperationsView() { IShipperOperations operations = new ShipperOperations(); INavigator navigator = new Navigator(); presenter = new ShipperPresenter(this,operations,navigator); //Instantiating presenter } ... } The basic structure of my presenter is something like this: public class ShipperPresenter { IShipper shipperView; IShipperOperations operations; INavigator

订阅 mvp