I have written before about the inherent problems with WPF's navigation engine, but thus far I have avoided the "roll your own" solution. Recently I started work on a Silverlight version of Magellan, and despite a promising start, I ran into similar problems with the Silverlight Navigation Framework. Where in the WPF version I was content to just live with the problems, the Silverlight version simply wouldn't work - URL's would be broken and the 'back' button would bypass controllers completely. So until I do this there will be no Silverlight Magellan.

This means that Magellan, which was originally all about MVC, is getting it's own navigation framework. Here are some design goals:

Design Goals

• Memory management strategies should up to the developer. If a developer wants to keep a page in memory, they should be able to. If they want to have it garbage collected on a new navigation request, it should (in WPF, you can't be GC'd, and in Silverlight, you can't keep it in memory).
• Developers should be able to control the construction of pages. None of this "must have a parameterless constructor" baloney.
• Should be optional. Magellan will continue to work with the inbuilt frameworks, this will just be better.
• Works with the browser back/forward button and URL's. This seems to be easy in Silverlight, but not so easy for WPF XBAP's, so we'll see.
• Is based on SOLID principles and well tested. I've read the source code to NavigationService. It's a 4,783 line class. I can understand why it has design problems and hasn't changed since 2005 :-)
• A lot more control over the back and forward stacks

I don't like the idea of forcing views to inherit from certain classes to work within a navigation system. Ideally, a "page" should just be a FrameworkElement or greater (most probably a UserControl). A "frame" should just be a ContentPresenter. There should be no need to derive from a whacky MagellanPage base class.

I'll draw a lot of inspiration from ASP.NET's concepts of IHttpHandlers and IHttpModules and the routing engine, as well as frameworks like nRoute. The concepts of URI's and route handlers will be vastly seperated from the concepts of pages and content.

(More to come)