Bobby Heid
bheid at sc.rr.com
Sat Nov 3 23:04:22 CDT 2007
How about this. First off, I had it backwards, we used the MVP pattern (actually presenter first) rather than MVC. When you use the MVP pattern, you are separating the presentation from the logic. The view (the form) instantiates the presenter and the model. It then calls into the presenter for the equivalent of onload. The presenter then possibly calls into the model to get any data needed to initially show on the form. The presenter then calls into the view to display the data. So for instance: The view starts up, instantiates the presenter and the model, then calls the onload method of the presenter. The presenter may call into the model for a list of customers. The presenter then calls into the view to display the customer list. It doesn't care how the view displays the data. The user double-clicks on a customer in say, a list box. The view then calls into the presenter with the customer information that was clicked. It might call something like presenter.CustomerSelected(custID) The presenter may then call into the model to get the customer details with the custID The presenter then calls into the view to display the customer address1 - view.DisplayAdd1(addr1) The presenter then calls into the view to display the customer address2 - view.DisplayAdd2(addr2) The presenter then calls into the view to display the customer city - address1 view.DisplayCity(city) ... There should be little to no logic in the view. It is best (at least from what I understand) to implement the view and model via interfaces. This really comes in handy when unit testing as you can mock the view or the model after they have been tested. Using this pattern also allows you to easily modify or replace the view (or the model for that matter) as long as the it implements the view interface. Here are a couple of links that you may find useful: http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx http://www.eggheadcafe.com/tutorials/aspnet/3c7967cb-8b7d-4b1c-96f8-03499361 1626/aspnet-model-view-presen.aspx http://polymorphicpodcast.com/shows/mv-patterns/ http://blog.vuscode.com/malovicn/archive/2006/10/10/Model-View-Presenter-_28 00_MVP_2900_-pattern.aspx http://blogs.infragistics.com/blogs/tsnyder/archive/2007/10/17/mvc-or-mvp-pa ttern-whats-the-difference.aspx I know that I have probably not helped you understand any better. At first, I could not see the benefits of using this model, but now I am a believer. Good luck, Bobby -----Original Message----- From: dba-tech-bounces at databaseadvisors.com [mailto:dba-tech-bounces at databaseadvisors.com] On Behalf Of Bryan Carbonnell Sent: Saturday, November 03, 2007 10:47 PM To: Discussion of Hardware and Software issues Subject: Re: [dba-Tech] Model-View-Controller On Nov 3, 2007 6:15 PM, Bobby Heid <bheid at sc.rr.com> wrote: > I know this is probably clear as mud, but I am knew to this stuff. Yea. Mud. Still doesn't explain what it is. Or at least in terms I can understand. -- Bryan Carbonnell - carbonnb at gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" _______________________________________________ dba-Tech mailing list dba-Tech at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-tech Website: http://www.databaseadvisors.com