locked
Looking for guidance RRS feed

  • Question

  • Hi,
    I am developing a ASP.net 2.0 web app in C#.I am going to use MVP pattern.I am designing,my domain model first.I have 2 questions..

    1. I want to use 2- way databinding,with gridview,for which I can use objectdatasource..should i create an objectdatasource object representing my domain,since my classes in domain wont follow pattern required by objectdatasdource..

    2...In MVP pattern,how to trransfer data from presenter to model..use a dto,or directly model classes..

    thks
    Sunday, July 9, 2006 3:59 AM

All replies

  • I think you mean MVC.  In fact, if you are using code-behind model, you are using a variation of MVC (Model-View-Controller) pattern.  If you put your data access coding into another class, your can further decouple model with controller.  For more information, see:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/ImpMVCinASP.asp

     

    Monday, July 10, 2006 2:15 AM
  • As pyeung is saying you mean MVC.

    The main benefit of the MVC pattern is that you can change the view without changing the domain model. This is done through decoupling the view (of data) from the model.

    With this in mind, you can answer the questions, is it still possible to change the view without changing the domain model when you use objectdatasources to bind the gridview....Yes you can, do you want to change your domain model to make it posible to use objectdatasources, No, You can't change the view any more without changing the domain model.

    The same with the use of dto's. The benefit from using dto's is that you can aggregate data in one object so you don't have to make more than one call to get the data. This pattern is used when you have remote objects and heavy network traffic or allot of calls. Do you have that?

    Greeting Clemens

     

    Monday, July 10, 2006 5:57 AM
  • Yes, there is an MVP besides the MVC. Although the names should have really been switched.

    Anyway, within your view, you can do whatever you like. If ObjectDataSource is cumbersome (and it is), you can probably settle on IBindingList<T> where T is one of your domain objects. But all this is really an implementation detail of the view.

    By the way, you'll probably want to clone your domain objects before data binding them - that way you won't be able to adversely affect any object by accident. In winforms, it makes undo a breeze. Oh, and the presenter is the one in charge of doing the cloning.

    Don't forget the interface of the view in MVP - the presenter should only be aware of the interface, not the web forms implementation. The interface should expose high level concepts, like a get/set property called "Customer" - which would be data bound by the form, and events like "SaveRequested". The presenter would subscribe to these events, and, when called back, would retrieve the data bound Customer, and possibly save it by using some form of object-relational mapping. No DTO necessary.

    If, however, you are interested (for security reasons) in having presenters run on your IIS box in the DMZ, while your "business logic" would run on a separate server on your corporate network, then you'd have to take distribution concerns into consideration - but that's a whole 'nother topic.

    Monday, July 10, 2006 9:27 PM
  • There is an example of using MVP with ASP.NET here: http://www.codeproject.com/useritems/ModelViewPresenter.asp#EventHandlingWithMvp

    (i don't like the way they bind the presented and the view but other than that it is otherwise reasonable )

    Saturday, July 15, 2006 7:28 AM
  • Hi udi,

    My presenter is talking to interface view,but i am accessing data from view using simple data type getters like string..i dont want view to have model knowledge..

    Also, on my server i have IIS and SQL server..so no need for distribution..
    Saturday, July 15, 2006 5:23 PM
  • Why don't you want the view to be tied to the model? It does have to present its data, after all. One of the differences between MVP and MVC is the increased level of abstraction. Controllers in MVC dealt in buttons, text boxes, and strings. Presenters in MVP deal with view interfaces and domain objects.

    This leads us to some common basic interfaces like:

    public interface IEntityView<T> where T : IEntity {

    T Entity { get; set; }

    }

    In smart/rich client scenarios, a presenter would probably need to create an instance of the appropriate class that implemented the above interface in a fashion similar to this:

    IEntityView<Customer> customerView = myObjectBuilder.Build<IEntityView<Customer>>

    and pass it the relevant object from the model like so:

    customerView.Entity = Repository.Get<Customer>(customerId);

    Saturday, July 15, 2006 7:25 PM