Is using WPF navigation in standalone applications is best practice? And can it be used with WPF MVVM pattern?
To answer your second question, yes, WPF navigation can be used quite successfully with the MVVM pattern.
As far as the first question goes, the best answer is 'it depends'. Specifically, it depends on the application you are trying to create; some applications are logically 'navigation' applications, where the users are expected to navigate through a series of screens in some fashion, while other applications have different paradigms. The best advice I can give you is not to fight it - if your application makes sense in a navigation context, then by all means use WPF navigation, but if it doesn't then do not try to shoehorn it into one.
Perhaps the best way to determine whether or not your application uses a navigation paradigm is whether or not a back button makes sense; if it does, then you'll want to use Frame or NavigationWindow so that you can use the built-in WPF navigation support.
I don't think that System.Windows.Navigation is ready for production applications yet. I've found that using it in a WPF4 application is a frustrating experience if you need to pass data between pages.
I also encountered a serious bug that causes databinding to fail after using back or forward navigation.
Numerous WPF toolkits and frameworks exist for MVVM, MVC and MVP style applications. Virtually all of them replace the Hyperlink, Page, Frame and Journal classes that Microsoft provides with custom-built navigation services. So the developer community appears to have given System.Windows.Navigation a "vote of no confidence".
Hopefully support for navigation-style apps will improve in the future.
If you have an application that's suited to the navigation metaphor, it's probably worth investigating these alternative frameworks. (Of course, these toolkits have their own learning curve associated with them.)
I'm still searching for a good approach to this problem myself.
Related
I've been looking into adopting MvvmCross in developing our next generation of software, mainly with the aim of developing tablet UIs for it. I understand that MvvmCross does not currently support WPF but I can see ourselves developing that and contributing it back.
However, I've also noticed that MvvmCross seems to be very light weight in that there is little support for composite UI as described in the Prism guide.
Unfortunately, we do need to allow for more complex composited UI scenarios.
Given what is stated in https://stackoverflow.com/questions/10224376/mvvmcross-experiences-hindsight-limitations about forking or rolling your own with MvvmCross as a reference, and given that we do need more complex UI scenarios than those that MvvmCross provides, what would the best course of action be, fork and reimplement the parts of prism we need, try to get MvvmCross to work together with Prism as is, or develop our own from the inspiration of MvvmCross and MonoCross?
Update: See Second answer below...
I might need to write a longer answer to this tomorrow...
As an initial answer:
someone has already done a port of MvvmCross to Silverlight and the developers have suggested this might become available to the wider community
the PCL version of MvvmCross should be quite straight-forward to port to WPF - although possibly not if older .Net Runtime versions are required
as the chief dev of MvvmCross to date, I'm personally interested in supporting WPF - especially right now for my project http://github.com/slodge/BallControl which needs a desktop to run in (Windows Store is crippled - pah!)
composite UIs are supported in MvvmCross - e.g. tabs, pivots, panoramas, splits, modal children, etc - but there's not much work been done yet on a full composite UI like often seen in Prism.
I have seen people combine MvvmCross with other IoC frameworks, but (no work that I know of) has been done to date on combining MvvmCross with MEF (which is often used with Prism?)
If I were tackling this problem area, then I'd come at this:
Make sure we try to get a working app out first and foremost - the app matters more than the framework.
For framework, I'd try porting the basic IoC setup across first and some simple navigation
For the custom navigation (for displaying UIs in regions) I'd look at the role of the Presenter in MvvmCross - this is what I use in Tab examples, in iPad split view examples, etc to provide complex UI features.
If this custom navigation isn't enough I'd look at how it might be changed/replaced/extended - my guess is that the genuine requirements for WPF/Prism will actually be quite similar to the genuine requirements for bigger iPad, Surface and Nexus tablet apps.
I'd try to keep everything modular and optional so that small phone apps don't have to pull in big navigation processes that bigger apps might need. The downside of this might be lots of projects and DLLs!
I'd also be open to this splitting into separate project(s) - much of the modern software world is ruled by small targetted apps rather than bigger, sprawling frameworks.
Because I'm part time on Mvx, and this is your full time job, I'd definitely recommend you don't let Mvx hold you back!
My initial reaction is 'yes, I'd be really interested in working on this' - the downside (as above) is that I'm only spare time on mvx....
Here's the second answer...
I took the WinRT version of MvvmCross as a base (but also used elements of Console, WP7, Touch and Droid too)
I produced a simple WPF version of MvvmCross - https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/Cirrious.MvvmCross.Wpf
The main feature of this version is that it doesn't contain much in the way of navigation
e.g. don't try calling Back!
e.g. the main presenter is left abstract for the application UI to implement - see https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Wpf/Views/MvxWpfViewPresenter.cs
I then took the TwitterSearch demo app - https://github.com/slodge/MvvmCross/tree/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf
created some simple views (using cut and paste of Xaml from WP7 version)
created a simple Region based presenter - see how RegionAttribute is used in https://github.com/slodge/MvvmCross/blob/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf/MultiRegionPresenter.cs and in https://github.com/slodge/MvvmCross/blob/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf/MainWindow.xaml.cs
that was kind of it... give or take a couple of hours of debugging
There's a video of this in action - with some explanation at: http://youtu.be/pYkLxqpu_5E
This is obviously only a first step in Wpf support, but I suspect it is already going to satisfy quite a few use cases... Please feel free to fork the source tree and to extend or replace this first attempt. Also, if it doesn't work for you, then feel free to abandon it and try something else instead.
I will try to work on this more - but can't really prioritise it above paid work... but I am open to being paid to work on mvvmcross too :)
Seeing as how MVVM is being highly regarded as a good system design pattern, I thought I might just jump aboard and give MVVM a shot.
Just a little background about myself before I begin with questions:
I have done a few years of development with ASP.NET Webforms. I have also done a fair bit of development in ASP.NET MVC, which I am quite comfortable with.
Currently, we have a number of "backbone" applications written using ASP.NET MVC 3 which we customize and sell to our clients whenever we're approached. These applications are all meant for internal use, hence plug-ins wouldn't be much of a problem.
The real problem with development is that for large scale business applications with complex business rules, ASP.NET MVC tends to slow us down (writing jQuery / javascript > server side processing > return result, use jQuery to notify > alter view, something along this line).
Then I began looking for answers that will help us improve our time to delivery and also responsiveness (well, we all know how JavaScript is capable of killing us) and my search brought me to Silverlight (we have the time to change, no worries there).
So here comes the questions:
I have come across many Silverlight MVVM samples online, but all of them show applications as simple as interacting with only one Database table. Is MVVM pattern well suited for large applications?
In MVC, I'm used to Dependency Injection from Ninject to pass an implementation of UnitOfWork to my Controller. In all samples I found online, none of them use any form of DI. Is it really unnecessary? Since the idea of MVVM is to decouple, so why not also decouple ViewModel from Model?
I've gone through a book published by Jeremy Likness called Designing Silverlight Business Applications. He used MEF to do the decoupling, which I think doesn't really fit into our application. We do not really need to do "hot-plugging". What's your take on this?
MVVM is all about Commands, Databindings and No Code-behinds. What if I want to interact with UIs that do not expose to commands? (I'm not too sure about this, I'm guessing ListView OnSelectionChange?)
To add to the previous answer:
We are developing a large corporate-wide Silverlight platform and a set of applications using MVVM. Seems to be working pretty well.
We are using DI extensively. Our system is built on top of Prism. Prism contains a large amount of sample applications of various complexity illustrating the use of DI in MVVM.
We use Unity as our IoC container. Prism contains guidance for both MEF and Unity. Unity seems to be a more traditional IoC approach.
In the vast majority of cases using Bindings and Commands covered our needs. For the others we use Expression Triggers and Actions. You can also create custom Triggers/Actions if necessary.
I have no answers for all your answers (never used MEF) but I can tell you my experience:
1- I've been in the development of a quite-large silverlight application and MVVM fits perfect to have a maintainable application. The bigger problems we had because of application size were because of Silverlight, not MVVM 8-)
2- I haven't used it too much but it's useful in many cases. There are several toolkits to use DI with Silverlight like MVVM Light Toolkit:
http://compiledexperience.com/blog/posts/blendable-mvvm-dependency-injection-and-unit-testing
4- For interaction between UIs you can use the Mediator pattern. The same MVVM Light Toolkit has a Messenger to subscribe, send and receive messages and maitain every layer decoupled.
Hope this helps you ;-)
Given that C# is a leans more towards a strongly typed language, why did the designers chose navigation based on URIs over Classes?
NavigationService.Navigate(new Uri("/MyPage.xaml", UriKind.Relative))
fails at run time if MyPage is missing.
If there were a method that support passing a PhoneApplicationPage as a argument like
NavigationService.Navigate(new MyPage());
Navigation related errors can be caught at compile time.
Why was this not an inherent design in Silverlight/WP7 ?
Only the WP7 dev tools team can say for sure, but absent their input, I'll give it my best shot. My guess is that it arises out of using a plug-in framework for client application development. Web Silverlight doesn't even really have the concept of navigation. You can switch frames in and out of the applications main frame, but that's not really navigation persay. So, when they were asked to use Silverlight as a client application tool for WP7, they had to decide how they were going to navigate around.
The most obvious way to solve the navigation problem, if you're a team that's been building internet applications, is to make something as close to the internet model as possible. This allows developers to carry internet applications to the browser and do minimal rewrites of their code. Think about it, if you had a web application that used relative URLs to move between application pages, your WP7 could reuse most of that navigation logic with only slight modifications to use the new NavigationService. This also minimizes the changes from core Silverlight that the WP7 version has to make, making everything easier to keep synchronized between platforms.
It obviously isn't the best way of doing things, and it makes state maintenance between pages a royal pain in the ass, but I can at least see why they decided to do it this way. The main flaws, in my experience, are the runtime checking of navigation destinations (instead of compile time with classes), passing parameters (every page needs an OnNavigatedTo that parses out variables) and maintenance of non-trivial objects between pages (I've taken to just using Singletons to hold relevant objects as a sort of poor-man's cache). I'm hoping for at least some modification to the navigation paradigm in 7.5 or 8, but I'm not holding my breath.
This navigation model was inherited from Silverlight on the desktop (and WPF before it). It's important to note: this is not a String-based model, but rather a URI-based model. The difference here is key: we're not talking about an arbitrary string to point to some XAML, we're talking about a universal locator for a resource that is a page within the application. By addressing navigation this way, your application actually has more than one entry point -- any URI within the application can be a valid entry point. And by making navigation URI-based, you ensure that the "state" of your application as it relates to what you're looking at can be serialized, accessed at any time from any direction, etc.
Imagine, for example, that you have a link on a webpage (or in an email, or anywhere else) that you want to open in your application. Click the link, and because the URI fully describes the resource that the application should display (e.g. an item in a catalog, filters on a search, etc.), you can jump straight to it (a.k.a. deep-linking). This isn't implemented on Windows Phone 7 (at least not from other apps, but it's really how the back button, etc. work), but the model comes straight from Silverlight on the desktop (the Navigation framework is in the Silverlight SDK), and you can see where they might take it on Windows Phone in the future.
Again, the power of the URI is its universality -- it is a common way to identify a resource. Without it, you're stuck with a tight coupling of anything that wants to navigate into your application and the application itself.
Silverlight/WP7 navigation service is fairly lacking in many regards, but there are a fair number of frameworks around that allow you to navigate to the ViewModel/View. Some examples:
Windows Phone MVP
Columbus
Xamling Core
In Caliburn Micro (MVVM framework) you have a nice way of handling navigation using only ViewModels - "Screens, Conductors and Composition"
Also keep in mind that using frames you can use routing in Silverlight to map one or more user-friendly URLs to the same .xaml file. If you would specify only the view class then Silverlight wouldn't know to which URL to map to.
Passing query parameters for state managment might be ugly, but it allows your application to be stateless which has some advantages (e.g. deep links) and fits the stateless nature of http web applications.
We're just starting up a new (our first) Silverlight project where we want to make a back office silverlight application using MVVM. Our application will need navigation through some kind of menu UI.
I've been poking around the web finding various frameworks (Galasoft MVVM Light Toolkit / Silverlight.FX / Prism) to help with building a MVVM application but i find it hard to single out which one suits our needs the best.
Does anyone have any experience/tips on which one to pick for a larger application with many Views and navigation between them.
Also, is a navigation Application the best way to get a "framed" application (with navigation inside the frame) or is there a better way?
I'll throw in a vote for Prism/Composite Application Guidance...mainly because I've used it in a number of "for work" projects.
The modularity stuff is great - you basically code up individual projects as if they were miniature applications in their own right, and you rely on the region management paradigm to composite your multiple "modules" into one cohesive app.
It does get a bit annoying as the module count gets high, although you don't have to make each module its own project...
Take a look at this article written by Jeremy Likness. He is using Prism and Navigation framework and its a good article to get you going with. Its also not hard to take the sample he provides and apply some MVVM principles to it.
I really appreciate the question (and answers) we already have in “List of WPF functionalities that aren’t in Silverlight 3.” My allegedly new question narrows down the differences between WPF and Silverlight into the context of MVVM. Based on a Shawn Wildermuth MVVM sample project I downloaded from MSDN, I do see that, as of Silverlight 2, “Element Binding isn’t supported yet…” But this surely is just one detail and is this still the case? Is there a summary of MVVM-centered differences between WPF and Silverlight? Can we build our apps to move with more ease between the two technologies?
Update: Silverlight requires that calls to external resources be asynchronous whereas in WPF it can be synchronous or asynchronous. This requirement in Silverlight is due to the Web-based nature of the technology.
The pattern is identical, but the implementation may differ. Silverlight is missing some crucial pieces such as commands that mean you may need to put a little more effort into achieving an MVVM solution. However, at the end of the day, you'll still end up with M's, V's, and VM's.
Element binding is now available in Silverlight 3, along with a couple different options for implementing actions. There are behaviors, which are pretty easy to code, as well as commands if you use a framework like Prism (from the Microsoft Patterns and Practices team, not included in Silverlight by default). There's also the Visual State Manager, which is in Silverlight only right now, that handles a lot of the routine kinds of animations you might want if what you're doing is state-based.
Building apps to move between the two technologies is a different matter though. There are a number of XAML elements that are not supported on Silverlight (and some SL stuff not in WPF) and the underlying runtime is specifically kept small to facilitate web deployment, so there are and will continue to be a number of things missing. I don't think we'll see completely cross platform applications (code once, compile into both WPF and Silverlight without changes) in the near future and I think that in anything but the most trivial of examples the code revisions are going to be significant.
This doesn't mean that you can't apply MVVM to both or that the skillsets don't apply across both. If you are familiar with one, you're certainly 80% of the way there on the other immediately (that 20% can be tough though!) and understanding the pattern (I use databinding to get synchronization code out of the view and into the view model, I use commands/triggers/behaviors to remove actions from event handlers in the code behind of the view, etc.) means that you know what to do, even if how you do it is going to be a little different. From that perspective, I think we're about as close as we're going to get to achieving parity at a pattern level.
As for a summary of the MVVM pattern implementation differences between Silverlight and WPF, I haven't found one. Sounds like a good topic for a blog post from someone though...