I have a WPF application whose main window contains two panels. The layout is pretty standard. The left panel is a a list of objects. The right panel displays information about the object selected in the left panel.
Right now I have the left panel directly in the XAML of the window, although I'm thinking it should be its own UC/View. The right panel is coded as a UC. The ViewModel for the main window has a field that is the VM for the right panel (call it the properties VM). The properties VM encapsulates the data for the selected object from the model.
When a different object is selected in the left panel I see two options:
1) Instantiate a new instance of the properties VM and load the corresponding data from the model
2) Load the corresponding data from the model to the existing properties VM, and issue appropriate change notifications [My current implementation]
Is there an advantage or preferred way of doing things between the two options above? Am I missing a better third option?
* Edit * Maybe a better question is - what are the advantages and disadvantages of the two methods?
Thanks!
You are describing a very standard scenario in the MVVM world. I believe you have a slight architectural issue that when resolved would make this question moot. The 'list' from where you are making your selection should already be a list of view models that wrap the 'object' a.k.a model. The properties view should simply be databound to the selected VM.
Is there an advantage or preferred way of doing things between the two options above?
Not really, but it's probably simpler to just create a new instance and set the data-bound property to this instance instead of trying to re-use and update the state of an existing instance each time the button is clicked.
If you need to cache instances, you could use an IoC container or a custom cache container that resolves the instances for you. You could for example set up the container to always return the same instance of the same class or return a new instance each time depending on your requirements.
But there is "preferred way" really. Your requirements decide what would be the best way to solve your specific issue or use case.
Related
I have view like the image and ViewModel have commands to handle the button (1,2,3,4) clicks. In work area allow the user to give inputs. Depending upon the input users are allowed click the button;
Each Button leads one new Window(View with ViewModel; whose model will be taken from the inputs). The new window have its own logic to showing the data depending upon the model injected to the ViewModel.
As per the MVVM standards, where do I specify the respective View and ViewModels for the each Button? (In View / View model).
How can I specify the same?
Basically ViewModel is a link between View and Model, so each combination of View and Model should have a separate ViewModel (if valid).
In my experience in most cases we are dealing with two kinds of Views:
small views such as icons, advanced buttons and so on (which are more isolated and more likely to have no reference to their parents so they are easy to manage and to be generalized)
large views such as windows, panels (which have a lot of children and are more likely to be changed later)
For small views common ViewModels can be used for multiple Views. but as for large Views (considering possible changes in the future) it's better not to use a single shared ViewModel. however it's helpful to use a base ViewModel class to implement some shared functionality (if any).
So keeping that in mind and focusing to stay standard, I suggest:
ViewModels for secondary windows: (according to the question I think you need 4) Each have their independent functionality (you can derive them all from a BaseWindowVm).best practice here would be not to let them know about their parent (MainWindowVm) and just to set their event handlers when they are instantiated. This way you can avoid code coupling.
MainWindowVm: consists of 4 commands and some other inputs. Each command does these steps:
instantiates a View
instantiates a ViewModel for secondary window based on input
set Vm's event handlers
assign the Vm to DataContext of the View
add the Vm to some list in MainWindowVm (If you want to keep track of these windows)
ShowDialog()
The most important part is that since ViewModels communicate with each other, linking Views with each other only make it more complicated and more difficult to manage. so Views are like islands with bindings to their ViewModels and everything else is up to ViewModels.
I have a requirement to display a number of graph/chart "thumbnails". Clicking one will show an "expanded view" (in a separate panel) that displays a larger version of the chart, plus controls to view and manipulate the chart.
There will be a number of different charts, each plotting my data in different ways. Also, a given chart type may appear several times, each plotting a different subset of the data. The controls in the "expanded" view will also differ from one chart type to the next, so there is little commonality here.
I'm struggling to get my head around how to model all this in MVVM, especially given the need to dynamically create an unknown number of thumbnails (and in some cases multiple instances of the same type).
Thinking aloud, I guess I need a view/viewmodel that represents a single thumbnail (the view contains the chart component and the VM exposes the data to plot). I guess I also need a V/VM for the "thumbnail list" UI, responsible for creating the thumbnails and exposing them via a collection for binding to the list. But how does it instantiate these? A VM gets injected into its view, suggesting the "thumbnail list" VM would have to dynamically instantiate the thumbnail views - but a VM shouldn't have knowledge of views should it?!
Lastly, when I display the "expanded" view, it would make sense to (somehow) pass it the charting component/view that was used in the thumbnail, to avoid having to render the chart again, but how?
If it's relevant/helps, I'm using Castle Windsor for dependency injection, and the navigation features of Prism.
This is indeed a complex topic,...
I would suggest a VM for the list of icons not necessarily for the icon itself. this can be bound to properities of the IconListViewModels. Then you should think about a ChartViewModelFactory. Which works in conjunction with your DIC.
An important discussion is the VM-V marriage. View first or View Model first... one way could also be ViewResolver if which returns the matching view based on your view model... this can rely on some sort of conventions. So the final steps could be ask the factory for a view model find the matching view glue them together and bind them to a content presenter...
I hope this helps to get you started...
I'm trying to build a data entry form in wpf. To perform validation I apparently need to have an object attached in the datacontext of my grid. But how can I have one when I didn't create one yet?
How does it work?
For example, I have a screen with a datagrid. The datagrid contains users that were obtained from membership. Above the grid is a button: add user. When clicked a new window appears and the following can be entered: user name, password, email. To perform validation on the textboxes to see if they aren't empty. Now, it is my understanding that the way this works is by having an object attached to the window (datagrid datacontext). But how can I have it attached when it doesn't exist yet?
This is a case where MVVM design patterns are very useful.
Every WPF view has a corresponding view model object that the properties in the view are bound to. So your window with the data grid has a view model - its DataContext - and the view model has properties that are bound to properties in the view - e.g. the ItemsSource in the data grid is bound to a collection (see note 1).
The "add user" command (which is implemented as a RelayCommand in the window's view model) creates a new view (the new window) and its corresponding view model object (the new user), sets the view's DataContext to the view model, and calls ShowDialog to show the window. (See note 2.) If the user accepts the new object, ShowDialog returns true, and the logic in the command takes the view model object (which now contains whatever changes the user made) and uses the information in it to create a new model object and add it to the model. If the user cancels, ShowDialog returns false, and the command discards the view model object without creating a new model object.
Note 1: The collection here may be a collection of model objects, or it may be a collection of view model objects. It depends on whether or not you need anything that's not in the model for displaying the model objects in a data grid. It's common, in this kind of scenario, for the objects in the grid to be view models for the dialog - that is, the view model objects have properties implemented for both display in the grid and modification in the dialog window. On the other hand, if all the grid is doing is displaying data from the model, there may be no need for an intermediary object.
Note 2: Having the command create a WPF window violates a central MVVM design principle, which is that view models shouldn't create WPF objects. The reason for this principle is pretty simple: you can't build an automated unit test for this command, since it's just going to throw up a dialog and wait. There are all kinds of different approaches to this - see, for instance, this question, and Josh Smith's blog post on the Mediator pattern - and all of them involve delegating the creation and display of the actual dialog window to a separate service that can be mocked out for unit testing. If you don't want to choose one of those approaches up front, you can retrofit one into your application once you get this thing working.
The idea here is that you should attach an object which is slightly different from your business models. In your case it won't UserInfo (or whatever you have for users in grid). It will be some other class, more suitable for editing. In MVVM this class will be a ViewModel. This class will have some differences comparing to your regular user class, for example it may have some properties nullable (when you haven't set them yet). Also this class will handle validation. You should instantiate this class at the same time you're creating an editor window and put instance of this class into Window.DataContext.
Hmm, there is a lot in this question but I just created a screen with three data grids (I am using Telerik in this case) and under each datagrid is a button to add to the grid. No the window with the three datagrids has it's own view model. and each of the "pop up's" has it's own viewmodel, in this case all of these are user controls and I just create a new window and set window.content and call show dialog.
Communication is facilitated via "events" - not the standard events you are used to in .NET but in this case I am using Prism and it's CompositePresentationEvent class. When the user is done creating their new object they click add and I fire off this event with the "payload" being the object they created. The main window with the three grids listens for that event and has a method to handle it, in this case adds it to the ObservableCollection which is what I bind the grids to.
If I were you I would look into the various frameworks that are out there, Prism, MVVM light etc... Again, your question seemed rather broad, I tried to give an overview but I didn't go into detail, if you look into some sort of framework I think it will clear up a lot of these details for you.
When the users hit Add New, create a new blank copy of your object, and set the datacontext to that new object.
Set some kind of flag to identify that it is a New object. This can be the Id being NULL, 0, -1, etc or an ObjectState property set to New. That way all your validation rules apply, and once the user hits save you know to INSERT instead of UPDATE
I am developing a wpf desktop app with strict MVVM pattern.
Current my app is doing following things:
Showing a Treeview with HierarchicalDataTemplate.
User can expand or collapse Nodes.
User can add add new Nodes(Drag n Drop + double click).
Everytime a new Node is added Model is updated and Treeview is recreated based on Model.
Because Treeview is recreated, all nodes are shown as expanded after adding nodes.
I want to show nodes with their previous expanded condition. Is there any way to do this using MVVM ? What I have thought so far is
Model should not contain any data related to how to draw UI ??
VM should just get data from Model and put it in UI(and pass date from UI to Model) ??
Thanks for your thoughts. I may be way far out form rail. But just want to have some wisdom from you guys.
Thanks
PAIJA
If you haven't already, read this great article by Josh Smith: Simplifying the WPF TreeView by Using the ViewModel Pattern
Basically what he suggests there is to include a property called IsExpanded in your VM and bind the TreeView to it correctly so that the expanded/collapsed status is entirely controlled by the programmer.
One solution what I think could be is to stop the recreation of the tree, just update the model and only add nodeitems to the current node where you are dropping them. Just refresh the collections in model and dont refresh the tree. Let us know if this does't suits your architect.
Thanks,
Jagdev Josan
The view model can contain view related information, that is what it is for. It is a bridge between pure business and pure view. My view models usually expose a few business properties of an object and add a few related view properties. If all you need is business properties, then bind straight to the business layer. Its only when you need to do something like your situation here that you need a view model.
If you want to completely recreate the tree (which sounds crazy) you can store the expanded state of the nodes in your view model and bind them to the tree view items using an ItemsContainerStyle. that way when you recreate your tree view your previously expanded nodes will still be expanded.
So your wrapped business objects will contain an extra property IsExpanded that you can use to restore your tree view state.
P.s. did i mention its a bit over the top to recreate the tree view?
Say I have a WinForm CRUD(like) application. I want to follow best practices on this so I try and make it follow OOP and a n-Tiered design.
Unfortunately I am familar with the words but not the practice of them. So lets go with the following example: My CaseNote program. I have a tabbed application where you go to the search tab to find a member and then one of the options is to go to the CaseNote tab to create a new case note, look at existing CaseNotes, or create a follow up CaseNote to a Parent Note. All of this is for the member you selected from the search tab.
So if I am creating objects and passing them around to be used by different forms where should I be instantiating them? I had thought I would have 3 layers; UI, Object, DAL. Where I fall flat is where I instance tho objects. I can't instance them in the object layer, can I? Also, if I instance them on the form how do I pass them from form to form in a quite large app?
CaseNotes Screen Shot
If you want to look at some more words around this problem you want to look at MVP and MVC. (These stand for Model View Controller and Model View Presenter). Some people will shoot me down for saying this but they are quite similar in concept.
The aim of MVP and MVC is to allow you to design your application logic without even having to think about your application apperance. It also allows you to define your user interactions without implementing an actual GUI. Esentially your model is your application logic, your data, your classes which actually do stuff like talk to your database. Your presenter or controller is what interacts with your model and what controls your user interface and reacts to user operations on the interface. Finally your View is your winforms design or your web page.
I'm sure you will be able to find plenty of material on the web about this but to give you some concrete help with this problem should serve to inform and illustrate your reading.
The first thing you need to do is start creating your objects that represent your data. So you will have a CaseNote object which is contains the casenote data. You will have a case note data container of some sort such as a case note database. You can define the logical operations and properties of these as if they where real items.
Then you would move on to define your presenter or controller which will define the operations that you want to support from the GUI. At the same time you should define an Interface that will define for the presenter/controller what operations is can perform on the GUI. So for instance your presenter may expose a method called SearchForCaseNote which takes a string parameter. Your view Interface will expose a method called DisplayCaseNote. When a user clicks on the search button the view will pass through the command to the presenter which will then call the model to get the data. The presenter may format the data at this point, i.e. convert DateTime object to a string and then pass the data back to the view through the interface define method called DisplayCaseNote.
You don't have to use the View interface, you could call into the view directly, but having the interface means you can have many different view implementations.
One last thing i need to mention is where you create these different parts of your application. My view is everything thing should fall out from the presenter/controller. So when you application starts it creates the presenter/controller object which then create and displays your view passing itself as a variable to the view. The presenter/controller can then either create the initial models by loading them from disk or ideally discover them through a dependency injection container like unity. In fact using unity to discover the view implementation is probably a better idea again as it gives you true seperation between view and presenter/controller. When you come to move to another view, (i.e. open another window), your presenter/controller should expose a method such as DisplayDetailPage which the view calls when a button is clicked. This would create the presenter/controller for the next view which would in turn create the view and get a reference to the model.
Hope this helps.
I think you should use the RocketFramework