Hi

Im researching methods and design-patterns to separate UI's from logic and
model for the software Im developing at work (pretty generic UI's bound to a
datamodel etc). I have been working with dotnet for quite some time now
(~5yrs) but have never tried out any of these design patterns (MVC, MVP or
....) so its quite new to me.

If I separate the UI from the rest and make the UI know about "the rest" but
not the other way around. Is that a bad idea? To simple?

My view of the MVP-pattern is that it allows a sort of mediator (Presenter)
to maintain (get/set) the state of the View, listen to events delegated by
the view with void-no-params-metods and also do the appropriate modifications
to the model. Is that a correct view or have I missed the point?

How does these patterns exactly fit in the dotnet winform-model with
databindings etc? I can't use databindings with a MVP-pattern can I?

One other thing I'm struggling with is if I should loose winform and focus
on WPF instead. I have been looking on WPF for a couple of days but its seems
to be so much new... phew ... at the same time a want to learn ...

and then there are the (D)M-V-VM patterns for WPF ... and the MV-Poo pattern

I dont know what my question is here exactly ... guidance? enlightenment?
WinForm or WPF for ui-modularisation?, recommended design-pattern?, is there
any _simple_ example-projects for the different kinds of DP:s and the
differences between them, pros/cons over regular programming... ?

Following up on my own thread:

I have looked at the ContactDatabase-example by John Gossman and to me it
seems that the model-view-viewmodel-pattern is pretty much the same as MVP
except that the presenter/viewmodel doesnt handle states and doesnt receive
delegated events, but instead exposes ICommands's and exposes parts of the
model to be databound from the view. I could be completely wrong here of
course ... does this make any sense? I noticed for instance that John doesnt
use an interface, IView, in this example, but directly wraps the viewmodel in
the view, which in turn wraps the model ...

I dont know if Im wrong here but using a presenter to set/get the state of
the view (through IView) feels kind of backwards in a modern wpf app... ?

Hi,

Did you download and try the guidance automation toolkit and smart
client software factory ?

regards
nz


Maximilian wrote:
> Hi
>
> Im researching methods and design-patterns to separate UI's from logic and
> model for the software Im developing at work (pretty generic UI's bound to a
> datamodel etc). I have been working with dotnet for quite some time now
> (~5yrs) but have never tried out any of these design patterns (MVC, MVP or
> ...) so its quite new to me.
>
> If I separate the UI from the rest and make the UI know about "the rest" but
> not the other way around. Is that a bad idea? To simple?
>
> My view of the MVP-pattern is that it allows a sort of mediator (Presenter)
> to maintain (get/set) the state of the View, listen to events delegated by
> the view with void-no-params-metods and also do the appropriate modifications
> to the model. Is that a correct view or have I missed the point?
>
> How does these patterns exactly fit in the dotnet winform-model with
> databindings etc? I can't use databindings with a MVP-pattern can I?
>
> One other thing I'm struggling with is if I should loose winform and focus
> on WPF instead. I have been looking on WPF for a couple of days but its seems
> to be so much new... phew ... at the same time a want to learn ...
>
> and then there are the (D)M-V-VM patterns for WPF ... and the MV-Poo pattern
>
> I dont know what my question is here exactly ... guidance? enlightenment?
> WinForm or WPF for ui-modularisation?, recommended design-pattern?, is there
> any _simple_ example-projects for the different kinds of DP:s and the
> differences between them, pros/cons over regular programming... ?