Prism and Dependency Injection - Unit Testing

Topics: Prism v2 - Silverlight 3, Prism v4 - WPF 4
Jul 29, 2013 at 2:29 PM
Dear Prism developpers,

Could someone be so kind and explain why are the RequestNavigate methods for IRegionManager defined in RegionManagerExtensions as extension methods?

How can I UnitTest that?
Wouldn't it be lovely to write:
var regionManager= Substitute.For<IRegionManager>();
regionManager.Received().RequestNavigate(Arg.Any<string>,Arg.Any<string>);

I'm also wondering why IInteractionRequest is not defined as IInteractionRequest<T> where T: Notification and defining void Raise(T context) and void Raise(T context, Action<T> callback)?

I know, I know, you're probably going to answer: we didn't want to break the interfaces, ect...

But now, you've got hundreds of developpers who need to implement dummy classes and interfaces to extend what's missing...
:-(

Additional question: why is PopupChildWindowAction not available for WPF?

Thanks a lot for all your good and time (if not life)-saving work,
Stephan
Developer
Jul 29, 2013 at 7:04 PM
Hi Stephan,

Based on my understanding the main reason behind why those were designed as extension methods is because the navigation functionality is not pertinent to the IRegionManager itself, but to each specific region. We could say that the RequestNavigate extension method is a kind of "convenience method" that simply delegates the navigation request to the RequestNavigate method of the corresponding region. The following sentences are equivalent:
regionManager.RequestNavigate("RegionName", uri, callback);
regionManager.Regions["RegionName"].RequestNavigate(uri, callback);
I believe the same applies to the IInteractionRequest interface. Said interface declares an EventHandler which could be invoked directly when needed. The Raise methods of InteractionRequest<T> are again a kind of "convenience methods" which simply raise the aforementioned event. Therefore, I believe that implementing those methods should not be required for a class to be an IInteractionRequest implementation.

Finally, the PopupChildWindowAction is not available in WPF because of a "limitation" within WPF itself: once a Window is closed, it cannot be used again. When you use a PopupChildWindowAction and set its ChildWindow, an instance of that window is created as part of the XAML markup and passed to the PopupChildWindowAction. The first time the corresponding InteractionRequest is raised, the window would be shown correctly. But the following times the window will not be shown, as it was closed and cannot be used again. The action cannot create a new instance of the window either, meaning that in WPF a PopupChildWindowAction could only be used once. This "limitation" is not present with Silverlight's ChildWindows, as they can be reused multiple times without problems.

If you want to use a similar functionality in WPF, I believe you could find the PopupWindowAction portrayed in the following blog post useful. Instead of receiving a Window it receives view which wraps in a new Window each time the InteractionRequest is raised, allowing it to be used multiple times:
I hope this helps to give some light on those topics.

Thanks,

Damian Cherubini
http://blogs.southworks.net/dcherubini
Jul 30, 2013 at 8:05 AM
Hi Damian,

Thank you for your enlightening answer!

I'm still unhappy regarding Unit Testing though ;-)

Stephan