I am creating a new winforms application that will have datagridviews which will load matrix data, and I want the user to be able to do a bunch of operations on the data, like showing/hiding columns, editing cell values, and filtering too.
I thought of using the MVP pattern (Model, View, Presenter).
I wanted to create a presenter class, which would handle all the logic (meaning any events that the user triggers), eventually end up in the presenter which will work on the raw data (the matrices). This seems logical up to now but my question is what do I do if I want to pass the controls themselves (like the datagridviews)? Should these controls be sent the presenter class or is that bad design?
Perhaps it's better to find ways to only modify the raw data and then update my datagridviews?
It is not a good idea to pass around controls. If you're going to use a pattern such as "MVP", then you should have the "model" contain the representation of the "view". In this case if there are various details pertaining to a set of data it belongs in the model. Then you pass the model around.
Perhaps it's better to find ways to only modify the raw data and then update my datagridviews?
So, to answer this question, "yes". Use the model to wrap the data and pass it around.
Update
Specifically, with WinForms controls belong to containers, being that they are reference types and have lots of exposed events you run a HUGE risk of passing a reference from one Form to another Form. Now, imagine that the first Form is done being used and closes and disposes, it kills the reference to the control and attempts to unwire events. Do you see where I'm going with this? It quickly becomes a nightmare trying to correctly cleanup references, and un wire event handler and since controls belong to one container by design it breaks that paradigm.
It's better to have a separation of concerns. If you need a view to have certain data, it's always best to pass around the data itself...
Related
This may be a really basic question to experienced programmers but I started on VB6, and now I'm trying to accomplish same stuff on C# which is object oriented.
Suppose I have a class with a method to add two numbers on textboxes and I run that in the click handler of a button (Doesn't matter if it is static or not), then I have the result and I display it on the screen (maybe in another textbox), the user click another button, how do I recover the result on the other button handler?, what's the best practice?, I know I can read the result on the textbox, but if the result was displayed on a Messagebox.Show or in console?.
What's the best practice to save results instead of using helper textboxes or global variables?
On VB6 I use invisible textboxes, so my forms looks really messy, but thats the way to there.
Using C# + XAML + WPF
Usually that is what a model is for. It is the data-state of what is shown (and more, as some information may not be displayed at all times or just used as utility). The view often has a reference to the model which you then can access in the handlers and manipulate.
I'd suggest reading up on design patterns like Model-View-Controller and for WPF specifially Model-View-ViewModel.
Also, WPF has a few powerful mechanics like data binding, which makes synchronizing your data with the view a lot easier, do not treat your view as a model.
Events occur in our Model and ViewModel that necessitate creating the appropriate View. The question is how to do this and avoid having any View code in the VM or M?
Here's the sequence of events so you can see this dilemma:
The user sets a number fields in a form to start a long running background process and then clicks the "Start" button. If this long running process succeeds then it needs to popup a chart with graphs to show the results. However, if the data fails processing for any reason then it can't popup charts, instead it logs an error message which is show in the a text box on the form.
Right now, that start button calls a method in the ViewModel which actually starts the background thread.
Only the background can determine when or if to create the view.
Currently we have this working by using an interface called ChartInterface. The view implements this interface and then sets a callback delegate all the way down to the backend model. When it decides to create the Chart it invokes the callback and uses the interface to pass the appropriate data and such.
However, this presents a problem because it can potentially produce dozens or hundreds of charts. So we need to have a "Dashboard" with a list of all the charts for the user to select which one to see.
So now the backend needs to decide when or if to create the Dashboard View, then add Chart View to it.
So it's getting messier because there will be increasingly more of these situations as we have lots of Models that need views so creating tons of callback delegates gets ugly fast.
An idea that seems to simplify instead of lots of callbacks will be to only pass an interface to a ViewBinder to the backend. Then each time it creates a model object, it can pass it to the ViewBinder to see if it wants to bind any view object to it.
Our thinking is that most any of the backend objects will be interesting (eventually) to monitor graphically. So if everyone of them after contructing is passed to the ViewBinder interface, then the view can decide if it wants to bind anything to it.
This is sounding better all the time.
The answer became clear while working on the code.
public interface ModelBinderInterface {
void TryBind( object model);
}
instead of one global "server locator" it's more natural for EVERY view object to implement this interface.
Then when it creates any ViewModel objects it assigns itself to the ModelBinder property of the the viewModel object.
Now the ViewModel can pass this same interface to the back end process.
When ever any relevant model gets instantiated, then it calls the ModelBinder with the object.
Then the View object can decide if it can instantiate the object, if not, it can pass the call up to it's parent which also implements ModelBinderInterface.
This way each view can handle instantiating views that it understand whether that be adding a control to a DataGridView or binding the object to a ListView, etc.
Of course, this still allows for a singleton ModelBinder because the lower levels can keep handing the call up to the top level application ModelBinder which there's only one and it can offer singleton instances.
In my application, different controls are only used dependent of the values of properties from a particular object. The forms constructor accept this object as a parameter.
The form has always some basic functionality, no matter what properties are set of the particular object.
Now I have something like this:
if(myObject.SomeProperty)
{
myControl.Visible = true;
myOtherControl.Visible = false;
// and so on
}
At this time, the controls that are dependant of SomeProperty are buttons and tab items. However, I can imagine that in the future other controls are added to the form and are also dependant of SomeProperty.
As you might guess, I want to set this up the right way. But I don't know exactly how. How would you implement this?
There are multiple ways I can think of solving this, depending on your situation you could select the best suited to you.
1. Databinding is one elegant solution when managing the state (visibilit or other properties) of multiple control's depend on a different object. Additional details in this question
2. You could write different functions if the combination of the states is only limited to couple of cases to at most 4-5 cases. That ways you can still reason about the methods which set the state depending on the object you are depending on. Ex: Basic_Editing, Advaced_Editing, Custom_Editiong etc.
3. If the number of cases are limited you could create multiple forms (User controls) and load them on demand based on the state of the dependent property (or object you are talking about).
Just having a bunch of if else's makes your code harder to maintain, or comprehend, logically group the states so that 1. You could reason about it later, 2.Someone else understands the reason/logic 3.When there is a change required it can be localized to one of these modular methods (techniques) reducing the time to fix, and test.
I would do it like this in form constructor:
myControl.Visible = myObject.SomeProperty && !myObject.SomeOtherProperty;
myOtherControl.Visible = !myObject.SomeProperty;
....
Is it the less code and its rapidly changing.
OR
You can create separate functions that will generate controls dynamically at runtime for each form view based on object properties.
First i can see you are setting visibility on/off it means you have already controls on the form every time.. , so that not a good practice, instead create controls only when needed.
As for your scenario you can have an function like Initialize() which contains all the code for checking if showing a particular control should be shown or not and then create it and add it to Forms control collection. If any new control come to be added later you have one function to update.
A more precise answer can be given if you can provide more detail to you scenario
I've started using the FormView control to enable two way databinding in asp.net webforms. I liked that it saved me the trouble of writing loadForm and unloadForm routines on every page. So it seemed to work nicely at the start when I was just using textboxes everywhere....but when it came time to start converting some to DropDownLists, all hell broke lose. For example, see:
Not possible to load DropDownList on FormView from code behind?
....and I had many additional problems after that.
So I happened upon an article on AutoMapper, which I know very little about yet, but from the sounds of it, this might be a viable alternative to two-way databinding a form to an domain entity object? From what I understand, AutoMapper basically operates on naming convention, so, it will look for matched names properties(?) on the source and destination objects.
So, basically, I have all my domain entities (ie: Person) with properties (FirstName, LastName, Address, etc)....what I would like to be able to do is declare my asp controls (textboxes, dropdownlists, etc) with those exact same names, and have automapper do the loading and unloading.
So if this worked, a person could just get rid of the cursed FormView control entirely, and it would be just one line of for binding and unbinding a webform.
(Yes, of course if I was using MVC I wouldn't have these problems, I know).
Caveat 1: AutoMapper would have to know the proper property name for each control type (the control itself would have the same ID as the property on the entity, but the behavior would depend on the control type), ie:
Person.FirstName --> form.FirstName..Text
Person.Country --> form.Country.SelectedValue
Person.IsVerified --> form.IsVerified.Checked
....so it would have to have the smarts to find the control on the form, determine its type, and then load/unload between the domain object and the webform control into the proper property of the control.
Caveat 2: Nested Controls - to complicate matters further, if one could pass a webform to AutoMapper (I don't yet know if you can), the source/destination controls are not necessarily in the root of the webform, so one would have to be able to perform a recursive search of all child controls on the passed webform (this is easy), returning a collection of all valid UI element type instances.
Caveat 3: User control UI elements are not public - when traversing the nested control hierarchy in #2, if you are using user controls, which do not expose their contained elements publicly (without hardcoding it so), one would have to do a FindControl for each element in the current AutoMapper collection. This one seems like a potential dealbreaker....
a) performance could be really bad (although if a User Control was found, it could be passed to the back of the queue and only processed if necessary)
b) from within an individual map function, how does one get reference to all the siblings of the current mapped element, in the current mapping function?
Any ideas??
Update
From what I've read, this seems like the path one would likely have to go down:
http://automapper.codeplex.com/wikipage?title=Custom%20Type%20Converters&referringTitle=Home
http://msdn.microsoft.com/en-us/library/ayybcxe5%28VS.71%29.aspx
I think your best long term solution would be to check out WebForms MVP - it provides a better abstraction layer over WebForms if you can't switch to an MVC environment. You would then have a much easier time mapping, as well as get the benefits of the MVP pattern.
I am trying to implement the MVP pattern for WINFORMS. Its a simple for with a button and a Grid, on button click, the grid will load, and user can fill in values into the grid.
For my button click event, I have something like this:
_presenter.LoadGrid();
Which is simple and straightforward.
My question is, in regards to grid...
I am planning to have a row click event firing....for enabling/disabling the subsequent input fields for the specific columns/rows of the grid etc.
I understand that the presenter should not contain any GUI elements and the View(form) shouldn't really contain Logic?
So, to have that GridRowClick event firing, I need to manipulate the grid (GUI) based on business rules (Logic). I am lost between letting the presenter handle the logic of that click event or the form?
If the presenter is to handle the click event, wont that include the gui components?
If the view is to handle the click event, the fieldnames etc are all business driven(logic), dynamically binded based on datatable returned from the business layer.
Any advice will be much appreciated.
Cheers
There are (at least) two variants of MVP.
Passive View Pattern
Supervising Controller Pattern
Passive View, as its name suggests, treats the UI as a more or less passive interface between the user and the application. It moves as much testable code to the presenter as possible leaving the view to handle only the most basic UI updates.
Supervising controller gives the view a little more responsibility by letting it handle data synchronization. This is usually done through data binding.
In either case event handling is accomplished by delegating to a presenter method:
EventHandler()
{
presenter.HandleEvent();
}
If handling the event requires making changes to the form, you expose what needs to be updated as a property:
public string PropertyThatNeedsToBeUpdated
{
get
{
return Control.Property;
}
set
{
Control.Property = value;
}
}
For Passive View, grids are a hurdle. Their complexity make it cumbersome to capture all the possible events. With Supervising controller, grids are much easier since you leave data synchronization up to the data bound controls.
You have to make the judgment call as to which is more appropriate for your situation.
The key is getting all that business logic into the presenter where it's testable.
The view should call the presenter to perform the business logic, passing the information needed (e.g. the data associated with the clicked row).
The presenter then performs the business logic and updates the data.
Depending on what type of changes you need to make, that might be all you need to do, since the existing data binding might be sufficient to update the view automatically. If it isn't sufficient, the presenter can make one or more calls to the view (via its interface of course) in order to make the required changes.
As you say, you should aim to minimize the amount of non-trivial code in your view, and in particular, the view shouldn't have any business logic in it.
EDIT:
Some good general information on MVP and other presentation patterns here: http://martinfowler.com/eaaDev/uiArchs.html
You might want to check out Part 4 of the video series from Polymorphic Podcast. He uses the supervising controller pattern and shows a technique for handling data grids. The whole series was actually a good introduction for me.
http://polymorphicpodcast.com/shows/mv-patterns/