
Portable prism
Dedicated to fans of the Microsoft Patterns & Practices group and just lovers of such a useful thing as Microsoft PRISM .
Developers who have met with Microsoft PRISM in their practice probably have a double opinion about this framework. On the one hand, in its 4th, and in order of the 3rd, version, it is a very powerful and flexible tool for creating composite applications, and on the other hand, a rather obscure and confusing library. But you can look at PRISM simply as an implementation of the MVVM template, which is essentially what PRISM for Windows Phone is.
I really like this MVVM implementation, and when I met the Portable Class Library, I realized that I needed a portable PRISM. Fortunately, the PRISM sources are available and remaking it on the Portable Library was not a very difficult task.
The task itself was to bring everything in common to the portable part and everything else to the platform-specific. But besides the fact that I like PRISM, I also like to use it with MEF, and MEF just with the advent of PCL2.0 appeared for WinRT in the form of Microsoft.Composition .
By the way, who does not know, Microsoft.Composition is built on PCL and, if desired, it can be built for PCL and used in Windows Phone 8 or directly in a portable library. True, here is the latest version of the source code on which the Microsoft.Composition NuGet package was built, I did not find on the project site on Codeplex .
So the MEF extensions for PRISM for WinRT had to be changed a lot so that PRISM could work with Microsoft.Composition. Nevertheless, most unit tests were able to be left with minor changes.
Who fundamentally understood how PRISM works knows that there are composite events that require Dispatcher to work with, and he is different on different platforms. In addition, the version for .NET used the WeakReference type , which is not available on some platforms. And I would not want to force someone who will use Portable PRISM to write some kind of initialization code each time that would implement these dependencies.
And then I found out that every .NET assembly has an initializer - in fact, a static constructor that runs once when the assembly is loaded into the application, but you just can’t write it down ... And then I came to the aid of the great tool of the Australian Simon Cropp , Fody .
This project was born from an extension project for Visual Studio Notify Property Weaver , which allowed, using Mono.Cecil after construction, to rewrite the properties of classes that were descendants of INotifyPropertyChanged so that they themselves would trigger a property change event when its value changed.
Fody has become a more universal extension of Notify Property Weaver , to which you can connect various plug-ins that will overwrite a specific part of the assembly. Many useful modules have already been written for Fody , which can be delivered through NuGet to a specific project. One of these plugins is ModuleInit.Fody, which can write to the assembly initializer a call to the Initialize method of the static ModuleInitializer class.
What I safely used.
It's funny, but ModuleInitalizers don't work on Windows Phone 7 . And it seems that no one is going to fix this bug. Well now at least static constructors work in pluggable assemblies .
WinRT Regions
are not included in the version for WinRT . I did not need them, and writing an adapter for Frame is not possible, so I decided not to transfer this functionality. Nevertheless, there are source codes in the project. So, suddenly someone needs to add them, you can do it. Windows Phone 8 In PRISM for Windows Phone 8, I basically copied the functionality of PRISM for Windows Phone 7, adding only WeakEvent since it is now available in Windows Phone SDK 8.0 and removed the classes related to AppBar since they are implemented there extremely crookedly. I think it’s much better to use the Cimbalino library to work with AppBar .
And so what are the NuGet packages:
I hope that my packages will be useful to those who like PRISM or who want to implement something implemented using PRISM to a new platform.
If someone needs other parts of PRISM as a portable version, for example, the Unity extension for WinRT, you can clone the Portable PRISM project on GitHub and add them. If you can’t build a project, write. I have not yet figured out how to configure .gitignore so that the information about NuGet packages is committed, but the packages themselves are not, and they can be downloaded again. So, who knows how to do this, tell me, please.
Developers who have met with Microsoft PRISM in their practice probably have a double opinion about this framework. On the one hand, in its 4th, and in order of the 3rd, version, it is a very powerful and flexible tool for creating composite applications, and on the other hand, a rather obscure and confusing library. But you can look at PRISM simply as an implementation of the MVVM template, which is essentially what PRISM for Windows Phone is.
I really like this MVVM implementation, and when I met the Portable Class Library, I realized that I needed a portable PRISM. Fortunately, the PRISM sources are available and remaking it on the Portable Library was not a very difficult task.
Porting
The task itself was to bring everything in common to the portable part and everything else to the platform-specific. But besides the fact that I like PRISM, I also like to use it with MEF, and MEF just with the advent of PCL2.0 appeared for WinRT in the form of Microsoft.Composition .
By the way, who does not know, Microsoft.Composition is built on PCL and, if desired, it can be built for PCL and used in Windows Phone 8 or directly in a portable library. True, here is the latest version of the source code on which the Microsoft.Composition NuGet package was built, I did not find on the project site on Codeplex .
So the MEF extensions for PRISM for WinRT had to be changed a lot so that PRISM could work with Microsoft.Composition. Nevertheless, most unit tests were able to be left with minor changes.
Abstract and Fody
Who fundamentally understood how PRISM works knows that there are composite events that require Dispatcher to work with, and he is different on different platforms. In addition, the version for .NET used the WeakReference type , which is not available on some platforms. And I would not want to force someone who will use Portable PRISM to write some kind of initialization code each time that would implement these dependencies.
And then I found out that every .NET assembly has an initializer - in fact, a static constructor that runs once when the assembly is loaded into the application, but you just can’t write it down ... And then I came to the aid of the great tool of the Australian Simon Cropp , Fody .
This project was born from an extension project for Visual Studio Notify Property Weaver , which allowed, using Mono.Cecil after construction, to rewrite the properties of classes that were descendants of INotifyPropertyChanged so that they themselves would trigger a property change event when its value changed.
Fody has become a more universal extension of Notify Property Weaver , to which you can connect various plug-ins that will overwrite a specific part of the assembly. Many useful modules have already been written for Fody , which can be delivered through NuGet to a specific project. One of these plugins is ModuleInit.Fody, which can write to the assembly initializer a call to the Initialize method of the static ModuleInitializer class.
internal static class ModuleInitializer
{
public static void Initialize()
{
InitializeCompositePresentationEvent();
InitializeWeakEventHandlerManager();
}
private static void InitializeCompositePresentationEvent()
{
var dispatcher = new Lazy(() => new DefaultDispatcher());
EventBase.InitializeDispatcher(dispatcher);
}
private static void InitializeWeakEventHandlerManager()
{
EventHandlerManager.Current = new WeakEventHandlerManager();
}
}
What I safely used.
It's funny, but ModuleInitalizers don't work on Windows Phone 7 . And it seems that no one is going to fix this bug. Well now at least static constructors work in pluggable assemblies .
Port Features
WinRT Regions
are not included in the version for WinRT . I did not need them, and writing an adapter for Frame is not possible, so I decided not to transfer this functionality. Nevertheless, there are source codes in the project. So, suddenly someone needs to add them, you can do it. Windows Phone 8 In PRISM for Windows Phone 8, I basically copied the functionality of PRISM for Windows Phone 7, adding only WeakEvent since it is now available in Windows Phone SDK 8.0 and removed the classes related to AppBar since they are implemented there extremely crookedly. I think it’s much better to use the Cimbalino library to work with AppBar .
What is now available?
And so what are the NuGet packages:
- Portable PRISM - Portable
- Portable PRISM - Portable - Interactivity
- Portable PRISM - WinRT
- Portable PRISM - WinRT MEF extensions
- Portable PRISM - Windows Phone 8
- Portable PRISM - Windows Phone 8 - Interactivity
What's next?
I hope that my packages will be useful to those who like PRISM or who want to implement something implemented using PRISM to a new platform.
If someone needs other parts of PRISM as a portable version, for example, the Unity extension for WinRT, you can clone the Portable PRISM project on GitHub and add them. If you can’t build a project, write. I have not yet figured out how to configure .gitignore so that the information about NuGet packages is committed, but the packages themselves are not, and they can be downloaded again. So, who knows how to do this, tell me, please.