Can somebody help me understand what the real difference is and why the MVVM Light toolkit users UserControl's for Views instead of Pages? I know there are some inherient differences between UserControl's and pages like access to the "NavigationService" on a page.
And some of the examples from John Papa's implementation of the MVVM Light use Page instead UserControl, but if you use the MVVM Light "View" Template it uses a UserControl.
thanks
dbl
A Page within a Silverlight application is designed to be hosted within a Frame - and is part of the navigation framework (see the MSDN Navigation Overview documentation). Applications of this style navigate from page to page, with the URL updating to reflect the current location, in much the same way as HTML-based websites.
A UserControl, is a re-useable unit of your user-interface. It is typically composed of a number of controls, UI elements - and may have some code-behind to perform logic.
If MVVM Light used Pages instead of UserControls, the framework would only be useful for navigation-based Silverlight applications, which are not terribly popular. However, UserControls can be hosted inside any other Panel or Page, therefore this approach is more flexible. A UserControl can be used as the content of a Page, but can also be used in many other contexts.
Related
I'm working on a windows WPF application using MVVM Light. As far as for switching views and navigation purposes, is there set classes readily available?
Right now, I'm using a MainViewController to load other views with datatemplate and messenger class. But i'm not sure if its the best practice.
Meant for switching is ContentControl but it has nothing to do with MVVM Light. Based on its Content you can assign diffrent Views. Take a look here.
I`m begginer in WPF and MVVM.
I created new navigation project which has mainMindow that contains frame.
I also created 3 pages and i want by binding commands from mainWindows to my ViewModel which implements the navigation between pages and show them via the frame.
My quastion is:
What is better to do:
Make each page as singleton or create the instances of the pages in my viewmodel?
Thanks
I recommend having a look at Prism.
Among other features, it provides a navigation infrastructure that you could utilize in your project.
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 am starting on a silverlight application and my MainPage is getting to be fairly large. I am not sure how to properly make a silverlight app in terms of object orientation or separating things into multiple xaml pages. Is it normal to have all of your application in the MainPage? For large elements such as a drawing tool, do people make custom controls and then add them in the main page?
I'm not really sure how to set this up and was hoping someone would shed some light on what the normal architecture of a silverlight app is.
As Steve B suggested you should look into MVVM and use that basic pattern to separate your application into views, models and view-models which bridge the gap between the view and the underlying models. The pattern is not difficult and works very well for data binding in WPF and SilverLight.
To manage the complexity of your main page use multiple UserControls to keep different parts of the UI in different files.
I notice that many of the WPF MVVM frameworks seem to avoid using the NavigationWindow and Page controls in favor of composing pages using nested UserControls.
The NavigationWindow and Page provide easy ways to enable back and forward navigation in the journal as well as providing an easy way to pass data among pages. Most MVVM frameworks I've seen re-implement these features in various ways.
Is there a specific reason to avoid using NavigationWindow and Page?
"NavigationWindow does not store an
instance of a content object in
navigation history. Instead,
NavigationWindow creates a new
instance of the content object each
time it is navigated to by using
navigation history. This behavior is
designed to avoid excessive memory
consumption when large numbers and
large pieces of content are being
navigated to. Consequently, the state
of the content is not remembered from
one navigation to the next. However,
WPF provides several techniques by
which you can store a piece of state
for a piece of content in navigation
history...."
http://msdn.microsoft.com/en-us/library/system.windows.navigation.navigationwindow.aspx
I just discovered another difference between UserControls and Pages: Pages cannot be used as DataTemplates.
For example, if you were creating application using the MVVM style, you might expect this to work:
<DataTemplate DataType="{x:Type ViewModels:ProjectDashboardViewModel}">
<Views:ProjectDashboardView />
</DataTemplate>
But if the ProjectDashboardView is a Page, it will fail.
I just found some other interesting information related to WPF NavigationWindow and Page on Paul Stovell's website.
He has this to say about the NavigationWindow class:
WPF includes a class called NavigationWindow, which is essentially a Window which also doubles as a Frame, by implementing most of the same interfaces. It sounds useful at first, but most of the time you need more control over the Window, so I've never had any need to use this class. I am just pointing it out for the sake of completeness, though your mileage may vary.
See his in-depth article on WPF Navigation and the Magellan and WPF Page management issues he encountered when writing his Magellan WPF framework.
Well, you're still going to use usercontrols to create reusable sub components, but as for app architecture, it comes down to use case really. If you're building a typical web application a Business/Navigation App should be fine. If you're writing a game, not so much. Likewise if you're doing something like an interactive advert or media player.