c# - Model-View-Presenter in WinForms -
i trying implement mvp method first time, using winforms.
i trying understand function of each layer.
in program have gui button when clicked upon opens openfiledialog window.
so using mvp, gui handles button click event , calls presenter.openfile();
within presenter.openfile(), should delegate opening of file model layer, or there no data or logic process, should act on request , open openfiledialog window?
update: have decided offer bounty feel need further assistance on this, , preferably tailored specific points below, have context.
okay, after reading on mvp, have decided implement passive view. have bunch of controls on winform handled presenter , tasks delegated model(s). specific points below:
when winform loads, has obtain treeview. correct in thinking view should therefore call method such as: presenter.gettree(), in turn delegate model, obtain data treeview, create , configure it, return presenter, in turn pass view assign to, say, panel?
would same data control on winform, have datagridview?
my app, has number of model classes same assembly. supports plugin architecture plugins need loaded @ startup. view call presenter method, in turn call method loads plugins , display information in view? tier control plugin references. view hold references them or presenter?
am correct in thinking view should handle every single thing presentation, treeview node colour, datagrid size, etc?
i think main concerns , if understand how flow should these think okay.
this humble take on mvp , specific issues.
first, user can interact with, or shown, view. laws, behavior , characteristics of such view described interface. interface can implemented using winforms ui, console ui, web ui or no ui @ (usually when testing presenter) - concrete implementation doesn't matter long obeys laws of view interface.
second, view controlled presenter. laws, behavior , characteristics of such presenter described interface. interface has no interest in concrete view implementation long obeys laws of view interface.
third, since presenter controls view, minimize dependencies there's no gain in having view knowing @ presenter. there's agreed contract between presenter , view , that's stated view interface.
the implications of third are:
- the presenter doesn't have methods view can call, view has events presenter can subscribe to.
- the presenter knows view. prefer accomplish constructor injection on concrete presenter.
- the view has no idea presenter controlling it; it'll never provided presenter.
for issue, above in simplified code:
interface iconfigurationview { event eventhandler selectconfigurationfile; void setconfigurationfile(string fullpath); void show(); } class configurationview : iconfigurationview { form form; button selectconfigurationfilebutton; label fullpathlabel; public event eventhandler selectconfigurationfile; public configurationview() { // ui initialization. this.selectconfigurationfilebutton.click += delegate { var handler = this.selectconfigurationfile; if (handler != null) { handler(this, eventargs.empty); } }; } public void setconfigurationfile(string fullpath) { this.fullpathlabel.text = fullpath; } public void show() { this.form.showdialog(); } } interface iconfigurationpresenter { void showview(); } class configurationpresenter : iconfigurationpresenter { configuration configuration = new configuration(); iconfigurationview view; public configurationpresenter(iconfigurationview view) { this.view = view; this.view.selectconfigurationfile += delegate { // iselectfilepresenter , iselectfileview behaviors // implicit here, in winforms case, call // openfiledialog wouldn't far fetched... var selectfilepresenter = gimme.the<iselectfilepresenter>(); selectfilepresenter.showview(); this.configuration.fullpath = selectfilepresenter.fullpath; this.view.setconfigurationfile(this.configuration.fullpath); }; } public void showview() { this.view.setconfigurationfile(this.configuration.fullpath); this.view.show(); } }
in addition above, have base iview
interface stash show()
, owner view or view title views benefit from.
to questions:
1. when winform loads, has obtain treeview. correct in thinking view should therefore call method such as: presenter.gettree(), in turn delegate model, obtain data treeview, create , configure it, return presenter, in turn pass view assign to, say, panel?
i call
iconfigurationview.settreedata(...)
iconfigurationpresenter.showview()
, right before calliconfigurationview.show()
2. would same data control on winform, have datagridview?
yes, call
iconfigurationview.settabledata(...)
that. it's view format data given it. presenter obeys view's contract wants tabular data.
3. my app, has number of model classes same assembly. supports plugin architecture plugins need loaded @ startup. view call presenter method, in turn call method loads plugins , display information in view? tier control plugin references. view hold references them or presenter?
if plugins view-related, views should know them, not presenter. if data , model, view shouldn't have them.
4. am correct in thinking view should handle every single thing presentation, treeview node colour, datagrid size, etc?
yes. think presenter providing xml describes data , view takes data , applies css stylesheet it. in concrete terms, presenter might call
iroadmapview.setroadcondition(roadcondition.slippery)
, view renders road in red color.
what data clicked nodes?
5. if when click on treenodes, should pass through specific node presenter , presenter work out data needs , asks model data, before presenting view?
if possible, pass data needed present tree in view in 1 shot. if data large passed beginning or if it's dynamic in nature , needs "latest snapshot" model (via presenter), add
event loadnodedetailseventhandler loadnodedetails
view interface, presenter can subscribe it, fetch details of node inloadnodedetailseventargs.node
(possibly via id of kind) model, view can update shown node details when event handler delegate returns. note async patterns of might needed if fetching data might slow user experience.
Comments
Post a Comment