lately i often see questions regarding MVVM and usercontrol, where - for me - view and usercontrol are mixed up.
for me a View when doing MVVM is just a pretty interface that allows users to interact with my ViewModels - so at least a collection of controls with Bindings. most time xaml only but codebehind not forbidden.
for me a usercontrol instead is not related to a viewmodel at all. the usercontrol has a representation in xaml and of course codebehind where properties, methods and Dependency Properties exist.
i'm on a wrong way with that?
EDIT: of course view and usercontrol inherit from UserControl class - so both technically UserControls. but i use just the term View when doing MVVM. and the term usercontrol just when there is no direct relation to a viewmodel.
ps: my english is too bad to write down what i mean...
You're not wrong just consider the fact the user control can be a reusable view that has a view model. cause the entire composite ui architecture is based on s shell(main window, view) and some regions with view (user controls)
A View and User Controls are totally different in MVVM.
The View is a conceptual name of the folder where you put all UI related stuff like user controls, windows, pages, etc. So the View is the folder that contains your GUI part for the particular application.
The User Control is the control which is configured by the developer by mixing multiple components / controls to work like a single control. A user control can also hold the other user controls.
The mix point is that, generally, views hold the user control in an MVVM application, as WPF is XAML based. It gets rendered in there, so the developer can plug your, his and other's user control into some where he wants to.
Whereas windows can not be placed into other windows. And pages can only be shown in frame element, so most views are user controls.
Related
I do not have enough information about WPF, so please correct me.
It seems that to handle different views create many usercontrols is needed(each view needs one usercontol which binds to the viewModel) , and also by using MVVM pattern designers can create views independently.
now if the designer tries to create two themes with different structure, he has to create two usercontrols because when using usercontrols the layout is specified(as mentioned here).
on the other way customControls do not specify the layout, so it seems that using CustomControls is more reasonable.
so the question: is using custom controls instead of usercontrols is correct, and if it is, is it reasonable for viewmodels to inherit from Control, and views become only styles for viewmodels?
Unless you need the functionality provided by custom controls, I would suggest using UserControls or DataTemplates. They are simpler. Here's a related question\answer.
WPF User Controls vs Custom Controls
I'm using WPF with the WAF framework.
I have a piece of UI (let's say it collects the user credentials) that gets presented on multiple views (see image).
I figured, hey, this is reusable, let's put it in its own user control.
I can get everything working fine if I ignore the inner user control and just "flatten" it if you will, but trying to encapsulate it is making me wonder what the best approach is. Should this "credentials" user control have its own dedicated view model? Should it be exposing its data through dependency properties instead? What's the best approach?
I will need to expose the data collected from the credentials control to the view model of the outer user control.
Should this "credentials" user control have its own dedicated view model? Should it be exposing its data through dependency properties instead? What's the best approach?
A UserControl can serve two purposes -
If you want to use it as a "Control" - which is often the case in a situation like this, I would treat it as 100% view. As such, I would not make the UserControl have a ViewModel at all (at least not publically), and expose it's properties via Dependency Properties. This provides the most flexibility in terms of reuse, as the UserControl acts like any other FrameworkElement, and can be dropped in and bound to your own properties in your other location like any other control.
When a UserControl acts as a View for a ViewModel, however, things are different. Here, the goal isn't reuse, but separation of concerns between your View and VM.
This situation sounds more like the first - you want to have a control that can be reused in multiple locations. In this case, this basically becomes a view element.
Do you know what is the difference between: User Control, Pages and Windows on WPF Browser Applications. I've found information related with this, but all the time are about WPF Desktop application.
Is it different for WPF Browser application?
I'm deploying an application but I don't know what is the best option for the Login section, the main section, the about section, etc.
Could someone explain me how can I use this tools in WPF Browser application?
Thanks in advance!
I use Pages in XBAPs the exact same way I would use a Window object in WPF. That is to say, rarely.
I usually have one Page/Window for my application and that is it. Switching the current view is usually done by switching a CurrentView property in my ApplicationViewModel, which changes what View is displayed in the main page.
I use UserControls when I want to create some kind of generic control, or for my Views. My Views can also be DataTemplates, and it is not uncommon for me to have a UserControl View that also has other Views in the UserControl.Resources (providing that all Views are related)
For example, I might have a UserControl called ProductsView which is the View that displays a list of Product objects, and the UserControl.Resources will contain a DataTemplate called ProductView which defines how WPF should display the ProductModel.
I'm working on a Windows Phone 7 app with a designer. I've done C# development with XNA so I know C# but was not familiar with the Model/View/ViewModel architecture.
Our first crack at it had multiple ViewModels active for any given view. Each ViewModel was an in-between layer for each object in our model.
For example: We had a "Friends" page that has a ListBox that displays the list of Friends. So we made a FriendsListViewModel that would handle getting an ObservableCollection<Friend> from the Model that the XAML would bind to. There were other functions available in the page (navigating to other pages, activating semi-related features, etc.) so that was contained in the FriendsPageViewModel.
This was starting to look crazy to me, so I made the relationship between View and ViewModel 1:1.
With all that described, I've got a question with two components:
With MVVM, what is the common relationship between Views and ViewModels? (focusing on Windows Phone 7 development here in case it's any different from ASP.NET, WPF, or Silverlight)
And as a possible addon to that question: Say the 1:1 relationship is the generally correct or accepted one: If you're dealing with something like a Pivot control or Panorama control, would you typically give each PivotItem or PanoramaItem its own ViewModel?
In MVVM, you typically have one ViewModel for each View (exceptions exist). The View typically 'binds' to the ViewModel which is the glue between the view and the data model. Your view can contain multiple controls and each control will bind to a particular property (i.e. data source) on your ViewModel. The ViewModel will then notify the View once one of these properties is updated (via the INotifyPropertyChanged interface in C#).
When thinking about ViewModels, don't think of it as a single ViewModel per control. Think of the control binding to a single property of the shared ViewModel.
The ViewModel provides data from the model to the View. The View should only be used to display the data it gets from the ViewModel. Keep code in the View to a mimimum and only pertaining to rendering control elements. The ViewModel is responsible for querying data from whatever the data source may be and then providing public properties the View can hook into.
This MSDN link has a pretty detailed article on it, but you can get a good synopsis on wikipedia.
Specifically in MVVM Light toolkit? I've not dove into the Prism code yet to see what it does in regard to regions in a WPF UI. Seems like with the messaging and the ViewModelLocator in MVVM Light you could do a similar thing....Can you? Can anyone give some examples on how you could do this? Essentially I'd like to click on a button and load two different view models into the UI. Perhaps a better way to explain is Outlook-like Navigation Pane functionality.
This can be done fairly easily in WPF, without any framework.
Just setup a DataTemplate in your Application (or at the Window/UserControl level) that maps the ViewModel to the View you wish to display for that ViewModel.
You can then just use a ContentPresenter, and bind it's contents to a single property (which can be of type object) within your ViewModel. When you want to set the "region" to a specific View, just set the property to the appropriate ViewModel, and WPF will automatically wire up everything for you.