Back in December, I mentioned that there were updates coming for application guidance on WPF/Silverlight (Prism) and for Windows Store Apps (Kona). Well, here's a few more interesting things to look at.
Kona: Guidance for Building Windows Store LOB Apps
The biggest news is that the Kona guidance for building Windows Store Apps is moving forward. Brian Noyes was on .NET Rocks last week (http://www.dotnetrocks.com/default.aspx?showNum=847) talking about the work that Microsoft Patterns & Practices is putting into their latest guidance package. If you're interested in carrying over a Prism-like development style to Windows Store Apps, then this episode is definitely worth the listen.
Kona isn't released quite yet; it's still in beta. But Brian mentioned that they are doing (near) weekly drops on the Codeplex pages; check out the latest here: http://konaguidance.codeplex.com/. At the time of this writing, the latest version is from February 22, 2013. It looks like the release will happen sometime in March, but keep your eyes on the site.
Why Not Prism for Windows Store Apps?
One question that came up during the .NET Rocks episode is why Kona is a separate guidance package rather than an extension of the current Prism framework. There are a couple of primary reasons.
First, Windows Store Apps are different enough from WPF and Silverlight apps that the approaches to development may not translate well. So, rather than trying to fit a square peg into a round hole, the team decided to start from scratch. The approach was to first build a Line of Business application (the type that a corporate developer might build) and then work backwards to see what common items can be made easier by extracting them into the Kona framework.
Next, there are certain things in Prism that just don't make sense in the Windows Store App world. For example, Prism includes extensive support for Regions -- a way to put different views into different parts of the shell. In the full-screen world of Windows Store Apps (it's killing me not to just say "Metro" here...), the idea of regions just doesn't fit.
Additionally, Prism has good support for dynamically loading modules. This gives you the ability to drop assemblies into a folder that can then get loaded into the application at runtime. In the Windows Store App world, all of the assemblies need to be included in the package that is submitted to the store. So, there's no way to just "drop in a new assembly". All of the functionality needs to be included up front.
So, it makes sense that the Kona guidance is separate from Prism. I haven't taken a close look at Kona yet (I still haven't jumped into the Windows Store App world), so I don't have any opinions at this point. But, if I do need to build line of business applications for Windows Store Apps, I'll definitely start here.
Prism 4.5
One other interesting thing that Brian mentioned is that Prism is basically "done". That doesn't mean that it has hit end-of-life or anything like that (so don't panic). It just means that the framework has gone as far as it needs to, so we shouldn't expect new features at this point.
Prism has been compiled to work against the .NET 4.5 framework (you can get the latest from Codeplex: http://compositewpf.codeplex.com/releases/view/95815). But the features and functionality are the same as Prism 4.1. Brian did mention that we can expect an updated version when Patterns & Practices releases the next version of Unity, but there won't be any new functionality.
Wrap Up
I'm not necessarily an advocate of using either Prism or Kona. As with any framework, you need to take a close look at the problems that the framework addresses. If you don't have those problems, then it's probably not the right framework for you.
As mentioned previously (Five Months In: Working with Prism and WPF), Prism worked very well on the last major project I was involved with. But we also had many of the concerns that the framework set out to solve (such as Regions, Navigation, Modularity, and MVVM helpers). Your mileage may vary.
It's always good to know what's available. Then we are more likely to pick the right tool for the job when it's time to build a particular type of application. Keep expanding the toolbox.
Happy Coding!
No comments:
Post a Comment