To address this concern, it’s possible to leverage Application Library Caching, which involves separating those libraries in ZIP files that are outside the XAP file, and should remain cached in the users’ browsers regardless of changes in the XAP. Prism supports Application Library Caching by, for example, providing the necessary metadata in the Prism assemblies to set them as external libraries.

However, when using Application Library Caching in Prism Modules, this doesn’t work out of the box. Let’s examine why this happens.

What happens with modules and Application Library Caching?

Agustin Adami and I examined the way Prism loads the content of module’s XAP files and found that the XapModuleTypeLoader reads the AppManifest.xaml file inside the module’s XAP file, searches for the Deployment.Parts elements and then loads the assemblies corresponding to the ones specified in the Source property of the AssemblyPart elements in the aforementioned XML element. However, dependencies that have been placed on a ZIP file using Application Library Caching are referenced in ExtensionPart elements inside the Deployment.ExternalParts element, and the physical file is stored outside the module’s XAP file (which is the only thing downloaded at this point.)

To illustrate this, here’s how the AppManifest for a certain module might look like:

 1 <Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" (...)>
 2   <Deployment.Parts>
 3     <AssemblyPart x:Name="SomeModule" Source="SomeModule.dll" />
 4     <AssemblyPart x:Name="Infrastructure" Source="Infrastructure.dll" />
 5   </Deployment.Parts>
 6   <Deployment.ExternalParts>
 7     <ExtensionPart Source="System.Windows.Controls.Data.Input.zip" />
 8     <ExtensionPart Source="System.ComponentModel.DataAnnotations.zip" />
 9   </Deployment.ExternalParts>
10  </Deployment>

Now, when a module’s XAP file has been downloaded, the XapModuleTypeLoader.HandleModuleDownloaded method is called, which loads in memory the results obtained by calling the XapModuleTypeLoader.GetParts method. This method ignores the Deployment.ExternalParts element inside the AppManifest.xaml file (as seen in the code snippet above):

 1 (...)private static IEnumerable<AssemblyPart> GetParts(Stream stream)
 2         {
 3             List<AssemblyPart> assemblyParts = new List<AssemblyPart>();
 4 
 5             var streamReader = new StreamReader(Application.GetResourceStream(new StreamResourceInfo(stream, null), new Uri("AppManifest.xaml", UriKind.Relative)).Stream);
 6             using (XmlReader xmlReader = XmlReader.Create(streamReader))
 7             {
 8                 xmlReader.MoveToContent();
 9                 while (xmlReader.Read())
10                 {
11                     if (xmlReader.NodeType == XmlNodeType.Element && xmlReader.Name == "Deployment.Parts")
12                     {
13                     // Deployment.Parts is examined, but Deployment.ExternalParts isn't
14                          using (XmlReader xmlReaderAssemblyParts = xmlReader.ReadSubtree())
15                         {
16                             while (xmlReaderAssemblyParts.Read())
17                             {
18                                 if (xmlReaderAssemblyParts.NodeType == XmlNodeType.Element && xmlReaderAssemblyParts.Name == "AssemblyPart")
19                                 {
20                                     AssemblyPart assemblyPart = new AssemblyPart();
21                                     assemblyPart.Source = xmlReaderAssemblyParts.GetAttribute("Source");
22                                     assemblyParts.Add(assemblyPart);
23                                 }
24                             }
25                         }
26 
27                         break;
28                     }
29                 }
30             }
31 
32             return assemblyParts;
33         }
34 (...)
35  

The Unity Solution

As a possible workaround to avoid this problem from happening, we created a modified version of the XapModuleTypeLoader (named LibraryCachingXapModuleTypeLoader), which loads the extension parts in memory before loading the assembly parts. To do this, we modified the IFileDownloader_DownloadCompleted method to obtain an ExternalPartsLoader from the container and call its LoadExtensionParts method before calling the HandleModuleDownloaded. The ExternalPartsLoader.LoadExtensionParts method basically searches for the AppManifest.xaml inside the XAP file, downloads the ZIP files containing the extension parts and loads the corresponding libraries in memory. Once this operation has finished, the HandleModuleDownloaded (which had been passed as a callback) is called, and the module loading process continues as it would regularly do.

To make this work, we had to create a class that inherits from ModuleManager and overrides its ModuleTypeLoaders property to use the LibraryCachingXapModuleTypeLoaderWith class instead of the regular XapModuleTypeLoader. We then overrode the ConfigureContainer method in the bootstrapper to register this custom module manager (named LibraryCachingModuleManager) in the container, so that it is used instead of the regular one.

You can find a sample that contains all the aforementioned modifications in my Skydrive account under the name LibraryCachingSupport.zip. This sample contains a Shell project and a module; both of which use Application Library Caching.

The MEF Solution

In the MefXapModuleTypeLoader a DeploymentCatalog is used to download the module’s XAP file and then compose all the parts defined in that file. Unlike in the XapModuleTypeLoader, it’s not possible to insert the external parts loading logic in the middle, so for this workaround, we had to opt out of the DeploymentCatalog and implement a similar functionality using the LibraryCachingXapModuleTypeLoader class.

Basically, the main aspect that should be considered for the MEF version is that the DeploymentCatalog, aside from loading the modules in memory, composes the parts discovered in it into the container. So, we added the logic to do so in both the LibraryCachingMefXapModuleTypeLoader and the MefExternalPartsLoader:

 1 private static void ComposePartsInContainer(Assembly assembly)
 2         {
 3             var catalog = new AssemblyCatalog(assembly);
 4 
 5             var batch = new CompositionBatch(catalog.Parts.Select(e => e.CreatePart()), null);
 6 
 7             var container = ServiceLocator.Current.GetInstance<CompositionContainer>();
 8 
 9             container.Compose(batch);
10         }

Additionally, we had to register the CompositionContainer in itself in order to be retrieved by the service locator in that piece of code.

You can find a sample that contains the MEF version of this approach in my Skydrive account under the name MefLibraryCachingSupport.zip.

Please note that this might not be the best approach to achieve this functionality, and it hasn’t been thoroughly tested; the intention of this post is to explain why this happens, and provide a possible workaround that might also serve as an example to implement the approach differently.

But first, let’s examine what happens with those resource dictionaries when they are specified in the Shell’s App.xaml, and why views can consume them even if they’re defined on a separate project. Resources defined in the App.xaml become available in the Application.Resources ResourceDictionary of the current Application class (which can be accessed through the Application.Current static property.) Once they’re available there, they can be consumed from within the XAML as static resources. Since modules are loaded into the same application domain as the Shell project, views defined there can access resources as long as they can be found in the corresponding Application.Resources dictionary.

You may have noticed that some times modules also contain an App.xaml file. This file isn’t loaded when Prism modules are loaded; only one Application class is instantiated, and that’s the one in the Shell project.

So, while defining the resources in the module’s App.xaml file would make them show in the designer, they wouldn’t work when the application is ran. Going backwards a little, Application.Current.Resources can be accessed from anywhere inside the Prism application (even modules), and the ResourceDictionary class supports adding new entries! So you might see where I’m going with this…

The approach

I tried programmatically adding new entries to the Application.Current.Resources dictionary and it worked! So this leaves us with two more needs in my opinion:

1. A way to get the resources to add from a XAML resource dictionary file (in the module, of course.)
2. A comfortable way to specify that the resources in that file should be loaded.

The first one was actually simple. We can create a new instance of the ResourceDictionary class passing the file’s URI as the source. As for the second one, I thought that perhaps abstracting the whole thing with an attribute might be a good idea. So, I created an attribute named ModuleResourceAttribute, which has a constructor that accepts a string as a parameter; this string should be the location of the XAML file, e.g. “/ModuleA;component/ModuleResources/Resources.xaml”. The idea is that this attribute could be specified on a module, like this:

1 [ModuleResource("/ModuleA;component/ModuleResources/Resources.xaml")]
2     public class ModuleA : IModule
3     {
4         (...)
5     }

Then, I created a simple service to load resources into the Application.Current.Resources dictionary:

 1 public interface IResourceLoader
 2     {
 3         void LoadModuleResources(Uri resourceUri);
 4     }
 5 
 6  public class ResourceLoader : IResourceLoader
 7     {
 8         public void LoadModuleResources(Uri resourceUri)
 9         {
10             var resources = new ResourceDictionary { Source = resourceUri };
11 
12             foreach (var key in resources.Keys)
13             {
14                 Application.Current.Resources.Add(key, resources[key]);
15             }
16         }
17     }

Finally, I created a modified implementation of the ModuleInitializer so that it checks if the module has any ModuleResourceAttributes to load the necessary resources prior to module initialization:

 1 public class ModifiedModuleInitializer : IModuleInitializer
 2     {
 3         (...)
 4 
 5 
 6         public void Initialize(ModuleInfo moduleInfo)
 7         {
 8             if (moduleInfo == null) throw new ArgumentNullException("moduleInfo");
 9 
10             IModule moduleInstance = null;
11             try
12             {
13                 moduleInstance = this.CreateModule(moduleInfo);
14                 this.LoadResources(moduleInstance);
15                 moduleInstance.Initialize();
16             }
17             catch (Exception ex)
18             {
19                 this.HandleModuleInitializationError(
20                     moduleInfo,
21                     moduleInstance != null ? moduleInstance.GetType().Assembly.FullName : null,
22                     ex);
23             }
24         }
25 
26            (...)
27 
28         protected virtual void LoadResources(IModule moduleInstance)
29         {
30             var attributes = moduleInstance.GetType().GetCustomAttributes(typeof(ModuleResourceAttribute), true).Cast<ModuleResourceAttribute>();
31             if (attributes != null)
32             {
33                 foreach (var attribute in attributes)
34                 {
35                     var resourceUri = new Uri(attribute.ResourceLocation, UriKind.RelativeOrAbsolute);
36                     resourceLoader.LoadModuleResources(resourceUri);
37                 }
38             }
39         }
40     }

I also created a little sample that portrays this, which can be found in my SkyDrive account under the name ModuleSpecificResourceDictionaries.

I hope you find this handy!

ObservableCommand

However, there’s a clever solution for this, devised by the Prism team in the View-Switching Navigation QuickStart. The idea is that the command can be reached through the Source property in the command binding, since that property allows one to specify where to look for the property to bind to. In the QuickStart, they define an instance of ObservableCommand as a resource in the user control that will have a command binding from a DataTemplate. ObservableCommand is a class that simply inherits from Prism’s ObservableObject<T> class specifying ICommand as the type parameter. This class has a Value property of type ICommand, a ValueProperty dependency property, and implements the INotifyPropertyChanged, which makes it possible for others to bind to its Value property and receive the changes in the element bound to it.

Sample Application

I’ve created a sample application to exemplify the use of the ObservableCommand to achieve command bindings from within DataTemplates, using Prism.

The sample contains a region inside an ItemsControl. The ItemsControl defines a button inside its ItemTemplate, which binds to a command that just pops a message in a message box. To be able to bind to the command, an ObservableCommand is used. The message to be shown depends on the string added to the region. The XAML for this can be seen here:

 1 <UserControl.Resources>
 2         <infrastructure:ObservableCommand x:Key="ShowMessageCommand" Value="{Binding ShowMessageCommand}" />
 3     </UserControl.Resources>
 4 
 5     <ItemsControl Regions:RegionManager.RegionName="MainRegion">
 6         <ItemsControl.ItemTemplate>
 7             <DataTemplate>
 8                 <Border Background="Cyan" HorizontalAlignment="Center" BorderBrush="Black" BorderThickness="3" Margin="5" Padding="5">
 9                     <StackPanel>
10                         <TextBlock>The following button is located inside a DataTemplate, and will show a message corresponding to the string added to the region.</TextBlock>
11                         <Button Width="100" Content="Show Message" Command="{Binding Value, Source={StaticResource ShowMessageCommand}}" CommandParameter="{Binding}"></Button>
12                     </StackPanel>
13                 </Border>
14             </DataTemplate>
15         </ItemsControl.ItemTemplate>
16     </ItemsControl>

You can find the sample in my SkyDrive account, under the name ObservableCommandSample.

I hope you find this helpful!

However, the auto generated proxy classes that are created when including WCF service references might not be easily integrated in a Prism application, which has testability requirements, and most likely uses a DI container.

Here I will show a possible way to add a reference to a WCF service inside a Prism Silverlight application, exposing the service functionality as a shared service.

The big picture

The sample application I created contains:

• An infrastructure project (HelloWorld.Infrastructure) with a Customer class and a ICustomerServiceAgent interface,
• A web project (HelloWorld.Silverlight.Web) that defines a WCF service using the Customer class (linked) as the data contract,
• A Prism shell project (HelloWorld.Silverlight) containing the Shell with the main region and the application bootstrapper, and a link to the ServiceReferences.ClientConfig file (necessary for the service reference to work),
• A ServicesModule that has a service reference to the WCF service defined in the Web project, and provides an implementation of ICustomerServiceAgent,
• A HelloWorldModule that consumes the ICustomerServiceAgent and displays the data obtained from the service in a DataGrid.

The CustomerServiceAgent class, defined inside the ServicesModule, is exported in the container using the ICustomerServiceAgent interface as the contract type, thus becoming a shared service that can be consumed throughout the application.

The implementation

The CustomersService, as defined in the web project, exposes simply a GetCustomers method which returns a list of Customer entities. Customer entities have a FullName, a Company and an Address.

The implementation provided for this service in the web project is a mock one, that simply returns a hardcoded list of customers, with a fixed name, a fixed company, and an address with random numbers.

Now back to the client side of the application, the ICustomerServiceAgent interface provides a LoadCustomers method that accepts a callback (which has an ObservableCollection of Customers as the parameter):

1  public interface ICustomerServiceAgent
2     {
3         void LoadCustomers(Action<ObservableCollection<Customer>> callback);
4     }

And then, the implementation of this interface in the ServicesModule consumes the WCF service through the auto-generated service proxy (which is the result of the service reference), and exposes the LoadCustomers method as defined in the interface, abstracting away the details of how the asynchronous request to the service is made:

 1 [Export(typeof(ICustomerServiceAgent))]
 2     public class CustomerServiceAgent : ICustomerServiceAgent
 3     {
 4         private readonly ICustomersService WCFServiceClient;
 5 
 6         public CustomerServiceAgent()
 7         {
 8             this.WCFServiceClient = new CustomersServiceClient();
 9         }
10 
11         public void LoadCustomers(Action<ObservableCollection<Customer>> callback)
12         {
13             this.WCFServiceClient.BeginGetCustomers(
14                 (e) => Deployment.Current.Dispatcher.BeginInvoke(
15                     () => callback(this.WCFServiceClient.EndGetCustomers(e))),
16                     null);
17         }
18     }
19  

You can find the solution in my SkyDrive account, under the name WCFServiceAgentSample. This code is provided “AS IS” with no warranties and confers no rights.

As a final note, It’s worth mentioning that, to prepare this sample, I checked the following blog post:

• WCF RIA Services DomainContext Abstraction Strategies–Say That 10 Times!

Even though I created a sample using a plain WCF service in Prism, the idea can be extrapolated to WCF RIA Services, using as well the abstraction strategies proposed in Dan Wahlin’s post.

Authentication and authorization are topics that are often discussed in the Prism community (for example, this work item or this thread), even though the Prism guidance does not provide support for these scenarios.

In this blog post, we will show a possible approach Agustin Adami and I thought to achieve authentication and authorization in Prism, by deciding which modules to load depending on the role of an authenticated user.

The big picture

The Solution contains a shell project, three modules and an infrastructure project.

The key components of this sample are located in the AuthenticationModule, which basically contains:

• An Authentication service, responsible of verifying the password of a user and returning his/her role.
• An Authorization service, responsible of providing a list of the modules that correspond to a certain role.
• A Login view, with its corresponding view model, which handles the interactions needed to authenticate a user, and navigates away once authentication is completed.

Once a user has been authenticated, the modules corresponding to his/her role are loaded, and the MainMenu view is shown. This view contains one button per module, each of which navigates to a view representative of that module.

The implementation

Both the authentication and authorization services are exported to the container, using interfaces defined in the Infrastructure project as the contract type. This allows other components to consume those services without necessarily being aware of the specific implementation used.

Authentication

This service provides a method that authenticates asynchronously, and invokes a callback in case it successfully authenticates (indicating the role of the logged user), and a different callback in case it can’t authenticate (indicating the error message).

Additionally, once a user is authenticated, his/her user name is stored in a property of the service. This is intended for other components to depend on this service and consume this information, and then provide a certain degree of customization (for example, showing a welcome text):

1 public interface IAuthenticationService
2 {
3     void Authenticate(string userName, string password, Action<string> successCallback, Action<string> failureCallback);
4 
5     string AuthenticatedUserName { get; }
6 }

It is worth mentioning that in a real scenario it’s likely that the information returned by this service will be more than just the role and the name of the user. We chose to include only that information to keep things simple.

Internally, the implementation of the Authentication Service consumes entities of type User from a repository (which in this sample is mocked but might point to, for example, a database).

Authorization

This service provides a method that asynchronously obtains a list of module names for a given role:

1 public interface IAuthorizationService
2 {
3     void GetAllowedModules(string role, Action<IList<string>> callback);
4 } 

In the sample, the Login view model consumes the information provided by this service, and then uses Prism’s ModuleManager to load these modules:

 1 private void LoginSuccess(string roleOfAuthenticatedUser)
 2         {
 3             this.authorizationService.GetAllowedModules(
 4                 roleOfAuthenticatedUser,
 5                 modules =>
 6                 {
 7                     LoadCorrespondingModules(modules);
 8 
 9                     (…)
10                 });
11         }
12 
13         private void LoadCorrespondingModules(System.Collections.Generic.IList<string> modules)
14         {
15             foreach (var module in modules)
16             {
17                 this.moduleManager.LoadModule(module);
18             }
19         }
20  

Internally, the Authorization Service consumes entities of type Permission from a repository (which is mocked in the sample but might point to, for example, a configuration file).

You can download the sample in my SkyDrive account, under the name AuthenticationAndRolesSample. This code is provided “AS IS” with no warranties and confers no rights.

I hope you find this useful!

In the Prism-v2 version of the StockTrader RI (which uses Unity), certain interface mappings for common services are registered in the container and certain views are placed inside regions in the MarketModule’s Initialize method, as shown in the code below:

public void Initialize()
        {
            RegisterViewsAndServices();

            this.regionManager.RegisterViewWithRegion(RegionNames.ResearchRegion,

 () => this.container.Resolve<ITrendLinePresentationModel>().View);
        }

        protected void RegisterViewsAndServices()
        {
            container.RegisterType<IMarketHistoryService, MarketHistoryService>(new ContainerControlledLifetimeManager());
            container.RegisterType<IMarketFeedService, MarketFeedService>(new ContainerControlledLifetimeManager());
            container.RegisterType<ITrendLineView, TrendLineView>();
            container.RegisterType<ITrendLinePresentationModel, TrendLinePresentationModel>();
        }

Therefore, the MarketModule class must inherit from IModule, so that the Initialize method is called as soon as the module is loaded.

However, in the Prism-v4 version of the StockTrader RI (which uses MEF), the MarketModule class is an empty placeholder which doesn’t even implement the IModule interface, which might seem strange at first sight. This is because, as explained in the class’s summary, every view and service present in the market module is discovered through the use of declarative attributes, such as the Export attribute for services, or the custom ViewExport attribute to register views in regions (which works in the the same way as calling the RegisterViewWithRegion method). Below you can find the class’s summary, which explains this situation:

This module is intentionally left empty because views, services, and other types are discovered through declarative attributes.

View registration for this module is done through the ViewExportAttribute.

If you extend this reference implementation and need to initialization when this module is loaded, uncomment the module export attribute, IModule interface, Initialize method.

I believe this is a good example that portrays the idea that Prism is a set of Guidance that can be used and modified to suit specific needs, and not a strict rule set to develop applications.

This is because, instead of throwing an exception, the RegionNavigationService exposes a NavigationFailed event which is raised in case an error occurs when attempting to navigate to a view in a region. This can be evidenced by this fragment of the ExecuteNavigate method, which is called inside the NavigationService when a navigation operation is requested:

 private void ExecuteNavigation(
NavigationContext navigationContext, object[] activeViews,
 Action<NavigationResult> navigationCallback)
        {
            try
            {
                NotifyActiveViewsNavigatingFrom(navigationContext, activeViews);

                object view = this.regionNavigationContentLoader.LoadContent(this.Region, navigationContext);

                // Raise the navigating event just before activing the view.
                this.RaiseNavigating(navigationContext);

                this.Region.Activate(view);

                (...)            

        }
            catch (Exception e)
            {
                this.NotifyNavigationFailed(navigationContext, navigationCallback, e);
            }
        }

Therefore, a possible way to avoid this from happening is to subscribe to the NavigationFailed event in the corresponding NavigationService instance, and perform the desired operations in response to that error in the handler for that event. The NavigationService instance can be found as a property of the Region involved in the navigation request.

Additionally, in case this behavior isn’t comfortable for your scenario, you can modify the Prism Library to make it actually throw an exception, in the catch block inside the aforementioned method for example.

You can find more information about Prism Region Navigation in this post from Karl Shifflett:

Prism v4 Region Navigation Pipeline

Now with Damian, Matias, Diego and Ezequiel we’ve released Prism Traning Kit 4.0, with the pre-existing labs updated to Prism 4.0, bug fixes from the first version and two new labs addressing Prism 4 new features:

A recent example that illustrates this is the release of Visual Studio LightSwitch, which has simplicity as its goal and essence. But perhaps a little bit subtler is the case of the Managed Extensibility Framework (MEF), for example, which makes it simpler to build extensible applications and components. Or even the .NET Framework itself, which allows developers to “apply common skills across a variety of devices, application types, and programming tasks”.

Nowadays I think it’s quite known that user experience is a key aspect of software development, and understanding that has made a difference in putting technology at the reach of several people, not only technical users. Without a focus on user experience, things like this wouldn’t be possible.

But the same principle applies to developers, I believe. As the means to build applications become simpler to use and repetitive or tedious tasks are taken care of by guidance, tools and frameworks, not only the number of developers grow, but also it is possible for us to dedicate more time to important aspects of software development (such as user experience, I would say).

I don’t think it’s a matter of capacity; it’s not that it is impossible to develop great software the hard way. In fact, some times that’s the only possible way. But by having  a developer experience-oriented platform, we can do more in the same time, and focus on what’s really decisive in terms of business needs.

However, I strongly believe it’s important not to sacrifice critical aspects of software development such as performance, transparency, among others. In the end, I believe successful technologies will tend to feature a balance between them.

Why WPF?

As mentioned in Adam Nathan‘s book ‘Windows Presentation Foundation Unleashed‘, there are six major benefits WPF has over the previous Microsoft technologies that shared its purpose (like GDI+, Windows Forms):

• Broad integration. WPF integrates all the necessary technologies for developing 2D, 3D, audio, video, rich documents, and so forth, avoiding the need to learn, and implement several independent technologies.
• Resolution independence. Due to the emphasis on vector graphics, WPF applications can be resolution independent, and contents of an application can automatically resize when the application itself resizes.
• Hardware acceleration. Since WPF is built on top of Direct3D, everything from 3D graphics to text gets rendered by hardware, making every application -not only games- benefit from powerful video cards. However, if no powerful hardware is present, WPF still has a software rendering pipeline so that the hardware isn’t a requirement for WPF applications to run.
• Declarative programming. The use of Extensible Application Markup Language (XAML) in WPF makes it possible to leverage the use of declarative programming to an incredible level of expressiveness, enabling graphic designers to contribute to not only the look and feel of the application, but also some behavior that is usually coded by developers.
• Rich composition and customization. WPF controls are extremely customizable, so it is possible to dramatically alter the looks of any control without affecting its functionality.
• Easy deployment. WPF provides support for deploying Windows applications through Windows Installer or ClickOnce, and even hosting them in a web browser (although the browser must be IE7 or further).

An interesting fact about WPF is that, apart from being part of the .Net Framework and designed for managed code, it is also implemented largely in managed code.

XAML

The introduction of this new markup language greatly simplifies the creation of a UI for the .NET framework, as it enables the use of declarative markup that directly represent the instantiation of managed objects, which can be later referenced through code-behind files. This is achieved by using partial class definitions; the window class is defined as a partial class when a window is created in XAML, and it’s explicitly defined as a partial class in the code-behind file.

This approach makes it possible to separate the UI runtime logic from the UI definition itself, which is an extraordinary benefit for making extensible, modular applications, especially if design patterns such as the ones facilitated by Prism are used.

Customization & Simplicity

At first sight, WPF may not seem easy to learn, since it introduces a lot of new concepts. But it has what I think is absolutely essential for any technology: it enables an extreme degree of customization, while keeping the simplicity of default values prepared for the most common scenarios. While I think both are very important, it’s not uncommon to see a technology sacrificing one to achieve the other. That’s what I think WPF accomplishes greatly, and I realize a lot of emphasis has been put in combining those two aspects. An example of this is the use of ControlTemplates: controls have a default template that defines their most usual appearance (such as a button being the typical grey rectangle we all know), but a custom template can be applied to completely redefine the way they look without altering, however, how they behave.

As for the learning curve, once you’ve grasped the main new concepts introduced in WPF (that is, the theory), everything else is really straightforward, and the initial overhead of learning those concepts is greatly compensated by the simplicity of creating applications with it.

Although XAML syntax may seem a little bit confusing at first sight, integration with Visual Studio and tools like Expression Blend makes it easy to develop applications without being an expert at all: just having an idea of what WPF is about is enough to start learning by trial and error and discover the whole new set of possibilities this technology offers!