mvp

I noticed that in the Webforms MVP implementation and most other examples, the Presenter usually attaches handlers to View events. Why can't the Views just call methods in the presenter directly? Just wondering, since the whole task of attaching a handler to an event, defining EventArgs for special parameters, checking if the event is null on the view side seems a lot more tedious than just calling a method. Sure they can, and I find that to be the best middle ground. What you are describing is I believe called Observing Presenter style. This allows you to completely decouple View from the

I use Model-View-Presentation Model in my application and I am wondering whether I need to create unit tests for the view. (I am on .net 2.0 WinForms) Now typically the view should be so simple that it should not be necessary to create unit tests for it. At least that's the idea I got from the goal of having the separation of View vs. Presentation Model (PM). And for the most part that is true in my code as well. However, there are cases where I can't seem to avoid some logic in the view. These typically have to do with Drag & Drop processing or advanced UI effects (imagine you're dragging a

I'm reading through Architecting Microsoft .Net Solutions for the Enterprise and I try to figure a couple of things out concerning the Presenter and the Service Layer. First off, my Presenter needs to call methods that reside in the Service Layer, like initialize(), save() etc. But where do I place a reference to the service layer? Should it be at class level in the Presenter, or should I define a new service in the presenter methods itself? Second - this isn't really clear in the book either - is this how the processing from the Presenter to the Service Layer works?: public void

I'm trying to use MVP and I notice that my View must know Model that should not happen in MVP I presume. here is example: public partial class TestForm : Form, ITestView { public void LoadList(IEnumerable<AppSignature> data) { testPresenterBindingSource.DataSource = data; } } public interface ITestView { event EventHandler<EventArgs> Load; void LoadList(IEnumerable<AppSignature> data); } public class TestPresenter { private ITestView view; public TestPresenter(ITestView view) { this.view = view; view.Load += View_Load; } private void View_Load(object sender, EventArgs e) { var data = // get

I'm trying to learn MVP, but something eludes me; if the Presenter uses the view as an interface, then the View cannot be just a simple rendering of controls. Imagine trying to write a typing-practice game, where words are randomly generated into the UI and the user must type the words as they fall down the screen. So the view is going to have methods like: public interface View { addWord(String word, double x, double y); // or possibly (Word word) moveWord(String word, double distance); removeWord(String word); setScore(int score); registerKeyListener(KeyListener listener); // other stuff }

If I am using the MVP pattern with GWT, as in the GWT architecture best practices talk from Google I/O from 2009, but have spread out the information into multiple widgets, how should the value object be populated? Say I have a EditPersonView/Presenter, a EditPetView/Presenter and an EditAddressView/Presenter and the last two are widgets as a part of a panel in the EditPersonView. With these I have the following class: class PersonDetails { private PetDetails pet; private AddressDetails addressDetails; // ... } The PetDetails and AddressDetails instance variables are managed in their presenter

Could any of you guys give a good explanation of the MVP pattern with regards to use in a GWT application. any example i have viewed, i found it hard to understand the concept of implementing the pattern. Questions such as what is it? what does it achieve, how is it implemented and how can it be extended for future modifications? http://code.google.com/webtoolkit/articles/mvp-architecture.html and http://code.google.com/webtoolkit/articles/mvp-architecture-2.html The primary goal of the MVP pattern is to separate the controlling of your UI from the implementation of your UI. You can think of