Glenn Block

• Composite Application Guidance is Live

  Before I go any further, we shipped! :-) Links: Composite Application Guidance Landing Page (will be at http://msdn.microsoft.com/compositewpf) Composite Application Guidance What's in the box Here's an overview of what you'll find At the core is the Stock Trader Reference Implementation. This app is a composite application built in WPF. In it you'll find design patterns, concepts and techniques you can add to your arsenal. Supporting the RI, you'll find a library which aids in implementing the patterns. The library is light, really light and that's deliberate. We harvested it out of the RI rather than building it first and throwing an app on top. We built it to work with your existing infrastructure rather than you having to build from scratch on top of it. We built it to work 100% with WPF rather than retrofitting WinForm concepts into a WPF world. Around the RI, you'll find comprehensive documentation (see the diagram above) in which you'll see the major design concepts and patterns are for building composites such as the RI. You can use this knowledge to build your own implementations if you decide that ours is not right for you. You'll also learn how we've decided to implement those patterns and concepts and why. You'll see how to use the pieces separately, or put them together in a coherent fashion to form the baseline architecture you see below. Finally you'll find a set of quickstarts and how-tos to help you get ramped up on the concepts. A little history If you'd have asked me 12 months ago, I would have said this day would have never come. Around that time we had just announced that we had no further plans to do anything in the CAB space. Instead our goal was to lead everyone toward a mythical creature called Acropolis. With Acropolis on the way it didn't make sense for us to continue. Then by some strange twist of fate, Acropolis was folded into future versions of the framework. This opened the door for us to address building Composite applications for WPF. Once we had the green light to go ahead, we had a tough decision to make, take CAB forward to WPF or start over. We chose to start over. 8 months later, we've incorporated tons of community feedback, built a new set of guidance specifically for building Composite applications in WPF. As it goes out the door, we're very happy we stuck to our guns on that decision. The Team We couldn't have done it alone. In addition to a fantastic, and extremely focused team including Brian Noyes from IDesign, Adam Calderon from Interknowlogy, Southworks and Infosys we had a large set of advisors. Across Microsoft, we had help from several product teams including WPF (Henry Hahn,Ivo Manlov,John Gossman,Mike Hillberg,Rob Relyea), UIFX (Brad Abrams and David Hill), DPE (Jaime Rodriguez, Karsten Junszewski, Jared Bienz, Mark Feinholz), and App Dev Consulting's Josh Twist. Combine this with an amazing committed group of partners (Infragistics), industry experts and advisors including David Platt,Jeremy Miller, Ohad Israeli,Oren Eini, Rob Eisenberg, Szymon Kobalczyk,Udi Dahan, and Ward Bell. This is just a sampling, the full list is below Bil Simser, Brad Abrams (Microsoft Corporation), Chad Myers, David S Platt (Rolling Thunder Computing, Inc.), Derek Greer, Ian Ellison-Taylor (Microsoft Corporation), Ivo Manolov (Microsoft Corporation), Jamie Rodriguez (Microsoft Corporation), Jeremy D. Miller (Dovetail Software), Josh Twist (Microsoft Corporation), Matt Smith (AltiMotion Corporation), Mark Tucker (JDA Software Group, Inc.), Michael D. Brown (Software Engineering Professionals, Inc.), Michael Kenyon (IHS, Inc.), Michael Sparks (RDA Corp), Ohad Israeli (Hewlett-Packard), Oren Eini (aka Ayende Rahien), Peter Lindes (The Church of Jesus Christ of Latter-day Saints), Rob Eisenberg (Blue Spire Consulting, Inc.), Shanku Niyogi (Microsoft Corporation), Scott Bellware, Szymon Kobalczyk (InterKnowlogy), Udi Dahan (The Software Simplist), Varghese John (UBS), Ward Bell (IdeaBlade) Final thoughts For me, this has been an incredible journey. I've had the pleasure of working with the most talented individuals inside and outside of Microsoft than I have to date. It just doesn't get any better than this! Thank you to everyone who has made this possible! As Soma likes to say Namaste! Posted Jul 02 2008, 11:19 PM by Glenn Block with 2 comment(s) Filed under: Composite Application Guidance, Composite Application Library, Composite WPF

• Composite Application Guidance - What is it?

  In the development of the Composite Application Guidance one area that we have labored intensely was around documentation. Documentation was so high on our priority list, that we deliberately reduced the number of bells and whistles in order to allow us to properly document what we had. As part of this we put in a significant effort to provide overview level information. We heard a lot of feedback from customers on the need for us to provide much more of the "Why" rather than the "What". Our hope when you see the documentation is that you feel we have provided enough background to understand what the guidance is and what problems it is solving. We equally want you to understand why we did what we did, how it benefits you, and when you should consider discarding out particular implementation. Below is our overview topic on the guidance pulled straight from out docs. (Forgive the crappy formatting, I tried :) )   The goal of this topic is to provide you with a high-level overview of the Microsoft patterns & practices Composite Application Guidance for WPF (Windows Presentation Foundation) and the development challenges it addresses. This topic describes some of the problems you might encounter when building complex WPF client applications, how the Composite Application Guidance helps you to address those problems, and how the Composite Application Guidance compares to alternative approaches. Application Development Challenges Typically, developers of client applications face a number of challenges. Most enterprise applications are sufficiently complex that they require more than one developer, maybe even a large team of developers that includes user interface (UI) designers and localizers in addition to developers. It can be a significant challenge to decide how to design the application so that multiple developers or sub-teams can work effectively on different pieces of the application independently, yet ensuring that the pieces come together seamlessly when integrated into the application. In addition, application requirements can change over time. New business opportunities and challenges may present themselves, new technologies may become available, or even ongoing customer feedback during the development cycle may significantly affect the requirements of the application. Therefore, it is important to build the application so that it is flexible and can be easily modified or extended over time. Designing for maintainability can be hard to accomplish. It requires an architecture that allows individual parts of the application to be independently developed and tested and that can be modified or updated later, in isolation, without affecting the rest of the application. Designing and building applications in a monolithic style can lead to an application that is very difficult and inefficient to maintain. In this case, "monolithic" refers to an application in which the components are very tightly coupled and there is no clear separation between them. Typically, applications designed and built this way suffer from a number of problems that make the developer's life hard. It is difficult to add new features to the system or replace existing features, it is difficult to resolve bugs without breaking other portions of the system, and it is difficult to test and deploy. Also, it impacts the ability of developers and designers to work efficiently together. The Composite Approach An effective remedy for these challenges is to partition the application into a number of discrete, loosely coupled, semi-independent components that can then be easily integrated together into an application "shell" to form a coherent solution. Applications designed and built this way are named composite applications. Composite applications provide many benefits, including the following: ·         They allow modules to be individually developed, tested, and deployed by different individuals or sub-teams, allows them to be modified or extended with new functionality more easily, thereby allowing the application to be more easily extended and maintained. ·         They provide a common shell composed of UI components contributed from various modules that interact in a loosely coupled fashion. This reduces the contention that arises from multiple developers adding new functionality to the UI, and it promotes a common look and feel. ·         They promote re-use and a clean separation of concerns between the application's horizontal capabilities, such as logging and authentication, and the vertical capabilities, such as business functionality that is specific to your application. ·         They help maintain a separation of roles by allowing different individuals or sub-teams to focus on a specific task or piece of functionality according to their focus or expertise. In particular, it provides a cleaner separation between the user interface and the business logic of the application—this means the UI designer can focus on creating a richer user experience.   Composite applications are highly suited to a range of client application scenarios. For example, a composite application is ideal for creating a rich end-user experience over a number of disparate back-end systems. Figure 1 shows an example of this type of a composite application. Figure 1 Composite application with multiple back-end systems In this type of application, the user can be presented with a rich and flexible user experience that provides a task-oriented focus over functionality that spans multiple back-end systems, services, and data stores, where each is represented by one or more dedicated modules. The clean separation between the application logic and the user interface allows the application to provide a consistent and differentiated look and feel across all constituent modules. Additionally, a composite application can be useful when there are independently evolving components in the UI that heavily integrate with each other and that are often maintained by separate teams. Figure 2 shows a screen shot of this type of application. Each of the areas highlighted represent independent components that are composed into the UI. Figure 2 Stock Trader Reference Implementation composite application In this case, the composite allows the application's user interface to be dynamic composed. This delivers a flexible user experience. For example, it can allow new functionality to be dynamically added to the application at run time, which enables rich end-user customization and extensibility. Architectural Goals and Principles The following table shows the architectural principles that have been prioritized by the Composite Application Guidance team's customer advisory board. These principles determine how guidance is developed and what the focus areas are. Quality Definition Subsetability This is the ability to adopt a portion of the Composite Application Library. You can choose only certain capabilities, incrementally adopt capabilities, and enable or disable features. Learnability This is the ability to quickly learn how to build WPF composite applications using the Composite Application Library. With small digestible and independent capabilities, you get started faster. Extensibility This is the ability to enhance, extend, or replace pieces of the framework without requiring you to redesign the framework or your application. Compatibility This means you can adopt the Composite Application Library for an existing application and you can use it with other existing infrastructure. Core services are swappable. Simplicity This means the Composite Application Library is designed in a minimalist way to reduce the amount of complexity. The Composite Application Library has just enough simplicity to get the job done. Testability The reference implementation in the Composite Application Guidance provides an implementation for Separated Presentation patterns. These patterns allow UI logic to be tested. Performance The Composite Application Library minimizes overhead while the application is running. Scalability The application can scale to support increased load. Upgradeability Existing WPF applications can be upgraded to use the Composite Application Library. Adoption Experience The Composite Application Guidance has an explicit goal to provide a good adoption experience. To deliver on this goal, the Composite Application Guidance provides the following: ·         You can "opt in" and "opt out" of the Composite Application Library capabilities. For example, you can consume the only services you need. ·         You can incrementally add the Composite Application Library capabilities to your existing WPF applications. ·         It is non-invasive because of the following: ◦       It limits the Composite Application Library footprint in the code. ◦       It limits reliance on custom Composite Application Library attributes. You can integrate existing libraries with the Composite Application Library through a design that favors composition over inheritance (this avoids forcing you to inherit from the classes in the Composite Application Library).   Concerns Not Addressed by the Composite Application Guidance Please note that the Composite Application Guidance does not directly address the following: ·         Occasional connectivity ·         Messaging infrastructure, including the following: ◦       Client/server communication ◦       Asynchronous communication ◦       Encryption ·         Application performance ·         Authentication and authorization ·         Handling thread-safety from background updates, including the following: ◦       Data races ◦       Data synchronization ◦       Handling UI updates from multiple threads (the Composite Application Library addresses some aspects of this) ·         Versioning ·         Error handling and fault tolerance   For more information about these topics, see the following resources: ·         Smart Client Architecture and Design Guide ·         Occasionally Connected Systems Architecture: The Client ·         Occasionally Connected Systems Architecture: Concurrency   Considerations for Choosing the Composite Application Guidance The Composite Application Guidance is for designing complex WPF applications. The scenarios where you should consider using the Composite Application Guidance include the following: ·         You are building a composite application that presents information from multiple sources through an integrated user interface. ·         You are developing, testing, and deploying modules independently of the other modules. ·         Your application is being developed by multiple collaborating teams. If your applications do not require one or more of these scenarios, the Composite Application Guidance may not be right for you. The Composite Application Guidance requires you to have hands-on experience with WPF. If you need general information about WPF, see the following sources: ·         Windows Presentation Foundation on MSDN ·         Sells, Chris and Ian Griffiths. Programming WPF: Building Windows UI with Windows Presentation Foundation. Second Edition. O’Reilly Media, Inc., 2007. ·         Nathan, Adam. Windows Presentation Foundation Unleashed. Indianapolis, IN: Sams Publishing, 2006. Posted Jul 01 2008, 05:22 PM by Glenn Block with 2 comment(s) Filed under: Composite Application Guidance, Composite WPF, prism

• How Prism supports using multiple IOC containers

  Today we received the following question / comment on our forums around our strategy for supporting multiple containers in Prism. This is something that I believe is on the minds of other folks using Prism. Below is a portion of the thread which you can access here Hi all, I'm currently getting up to speed with the Composite WPF project and looking to replace Unity with another DI framework (namely Ninject). Initially I had thought that it would just be a matter of duplicating some of the classes in the UnityExtensions project, ie the Bootstrapper and the ContainerAdapter. Indeed this works fine for an example as simple as HelloWorld and things are up and running in no time. However, when I try to modify StockTraderRI, I notice that the IUnityContainer is being passed around quite a bit - most modules require a reference to it and so do some controllers. For the cases where it's being used to resolve types in the controller and modules, it's acting more as a Service Locator and it feels to me that it would be cleaner to have these dependencies injected instead of explicitly requiring the DI container to resolve them (OrdersController for example). Now this is fairly easy to fix because the dependencies could just be directly injected in the constructor, or if they're not known at construction, then a specific factory could be injected instead of the DI container itself. The more complicated cases arise in the module initialization where the module needs to register/bind some types in the DI container. I haven't thought too deeply on this and it would be good to get some feedback as to what a clean solution would be so that the DI container is not required to be passed in to each module directly. One option would be to expand IContainerFacade a little to allow for the registration of types (with singleton options) - this would be quite easy and solves the vendor dependency, but it still smells a little because the entire container facade would still be being passed around to the modules. Another option may be to create an IModuleInitializer or IModuleRegistrar interface that gets bound during the module registration in the bootstrapper and passed in to the module constructor for use during Initialize (so we'd have, for example, a UnityNewsModuleRegistrar, a WindsorNewsModuleRegistrar, a NinjectNewsModuleRegistrar, etc). As the bootstrapper is already DI container specific, it's less problematic to do any binding here or to have a specific IModuleRegistrar rely on the container. Then, if the module requires certain objects from the DI container after the registration, it could either call something like IModuleRegistrar.Prepare(this) to have properties injected, or possibly cleaner would be to have factories for the required types passed in to the module constructor, which would be in turn initialized by the IModuleRegistrar ready for creating objects when the module needs them. One question that arises from this approach is, are we just replacing the module with the module registrar? If all the module is responsible for is type registration, then the answer is yes and it's kind of a moot solution - although I still feel the modules should then technically be called UnityNewsModule, UnityPositionModule, etc. I would argue though that module initialization is probably made up of a number of steps, of which the DI registration is only one - the rest is the logic around adding views to regions, running controllers, etc. If the DI registration step can be factored out into small, DI-specific registrars, then it makes it much easier to swap one DI implementation for another. So what do you guys think? Cheers, Michael Hi Michael Your observations are good ones. Supporting multiple IOC containers was an explict goal from the get-go in Prism. However early on we made a decision that doing so doesn't necessarily equate to the "one container to rule them all." We made the decision that "support" means that at the low-level (our 'framework) none of our apis explicitly depend on one container or another. On the other hand, at the high-level within the application we decided we should not have such an abstraction. The reasoning is very simple. Containers have different semantics and syntax. Part of the reason I choose to use Castle Windsor over Structure Map, NInject, etc is because I like the particular attributes of that container. If I like Structure Map's fluent interface then I want to use that, not some dumbed down abstraction. For this reason we very explicitly use IUnityContainer throughout the RI. We would equally expect if you used NInject then that is what you would use instead. Once I commit to a container, it's unlikely that I would want to change mid-way. However you want to make sure that whatever container you make the decision to use does not block your usage of the patterns and libraries. Now at the core levels, you would need an implementation of IContainerFacade for NInject, and possibly a Bootstrapper if you like the Bootstrapper pattern. In this way you can use Prism with any container, while at the same time leverage all of the specific benefits each container provides. As far as the module implementation itself, the reason we inject the container into the module is to allow registration of module-specific types AT load time. This way those types are only registered if the module is loaded. The module is not only used for registering but also instantiating views and controllers. We could have wrapped this with specific services like a ViewService and a ControllerService instead of using the container directly. However, we felt that had the same issues around losing container semantics and such. We could consider this for the future if this is what everyone wants though. Let us know if this rationale makes sense. Thanks for the feedback! Posted Jul 01 2008, 11:50 AM by Glenn Block with no comments Filed under: Composite Application Guidance, Composite WPF, IOC, prism

• Talking about Prism with InfoQ

  Recently at the ALT.NET Summit, I got a chance to sit down with Greg Young to discuss the work we've been doing in our new Composite Application Guidance (Prism). In the interview we talk about the guidance, what technical and architectural challenges it addresses including specific to WPF,how it differs from CAB, and how customers have been working with us to build it.   Access the interview here. Posted Jun 30 2008, 02:04 PM by Glenn Block with 3 comment(s) Filed under: Composite Application Guidance, Composite WPF, prism

• Composite Application Guidance, time to ship

  http://www.flickr.com/photos/ckaroli/1779555530/ The last time I did one of these posts, I was off on how close we were, by about a month. Well this time that's not the case. At the end of last week we dropped an RC for Composite Application Guidance AKA Prism. This week the only thing left to do is to ship. :-) If you checkout the RC, here's what you'll find. Stock Trader Reference Implementation Composite Application Library Quickstarts on UI Composition, Commanding, Event Aggregator, and Modularity One hands on-lab Comprehensive docs including patterns, design concepts, technical concepts, RI overview and API. Several spikes including a version of Family Show which we upgraded to use the CAL, and a version of our RI using Castle Windsor If you haven't been keeping up, we went through some significant changes over the past few iterations. At the top of the list we changed most of the places in the RI where we were implementing MVP to use Presentation Model. We also factored out our EventAggregator PrismEvent into a abstract BaseEvent and a CompositeWPFEvent. It's been a great journey getting here, one that many of you traveled with us. The team is thrilled to have reached the end of the road and to be able to deliver the fruits of our efforts. We're counting the grains of sand as they fall. Download the RC here. Posted Jun 30 2008, 01:58 AM by Glenn Block with 7 comment(s) Filed under: Composite Application Guidance, Composite WPF, prism

• StockTrader RI using Castle Windsor

  I am supposed to be working an article, but couldn't resist posting on this one. Our most recent Prism drop (now called Composite Application Guidance) includes a spike we did where we converted our reference app to use Castle Windsor. It was a pretty straight forward effort basically involving a search and replace for wherever we used Unity. We also had to create a Windsor adapter. Fortunately no attributes to remove or anything. There are a few places where we're pretty sure there's a more "Windsor-esque" solution than the way we have done it. I am sure once you guys get your hands on it, we'll soon know what those are. Get the latest drop here Posted Jun 12 2008, 01:16 PM by Glenn Block with 2 comment(s) Filed under: Composite Application Guidance, prism

• Loosely coupled communication - Prism style

  Francis has been a busy man lately on his blog with a series of posts on the various loosely coupled communication patterns and mechanisms we use in Prism. He gives a great overview of what they are and in which situations they are applied within our RI. Great work Francis! Decoupled Communication with Prism (intro) Decoupled Communication with Prism (Shared Views/Services) Decoupled Communication with Prism (Commanding) Decoupled Communication with Prism (Event Aggregation) Below are some slides from my Prism tech-ed talk which are illustrations of some of these. Posted Jun 04 2008, 12:31 AM by Glenn Block with 1 comment(s) Filed under: CAL, Composite Application Guidance, Composite Application Library, prism

• Ruby on Rails on the DLR, getting closer

  Just caught this little gem from John Lam on Twitter This is very good news. Posted May 26 2008, 11:21 AM by Glenn Block with 2 comment(s) Filed under: DLR, IronRuby

• Using ViewModels and DataTemplates to compose your UI

  Several drops ago we introduced a ViewModel composition spike. The purpose of this spike was to introduce a different way to compose your UI that WPF offers. That is instead of having your views and regions be UI-Elements, having them as pure models. What I mean by this is instead of having a Employee Region which is a tab, that contains EmployeeViews, you have a model (the region) that contains Employees. Likewise instead of of having a panel that displays a CustomerView, you have a  model that contains a single Customer. So how do I get my Employee region to display as a Tab, and my Employee to display itself in the same way as the EmployeeView? The answer is using DataTemplates. Using DataTemplates, you can define the UI rendering for a specific type (in this case the Employee and the EmployeeRegion). The nice thing for the no code-behind zealots among us is that there is absolutely NO CODE BEHIND in a DataTemplate. Below you can see an example of what an Employee template might look like. <DataTemplate DataType="{x:Type Employee}"> <Grid x:Name="GeneralGrid"> <Grid.ColumnDefinitions> <ColumnDefinition></ColumnDefinition> <ColumnDefinition Width="5"></ColumnDefinition> <ColumnDefinition Width="*"></ColumnDefinition> </Grid.ColumnDefinitions> <Grid.RowDefinitions> <RowDefinition></RowDefinition> <RowDefinition></RowDefinition> <RowDefinition></RowDefinition> <RowDefinition></RowDefinition> </Grid.RowDefinitions> <TextBlock Text="First Name:" Grid.Column="0" Grid.Row="0"></TextBlock> <TextBlock Text="Last Name:" Grid.Column="2" Grid.Row="0"></TextBlock> <TextBlock Text="Phone:" Grid.Column="0" Grid.Row="2"></TextBlock> <TextBlock Text="Email:" Grid.Column="2" Grid.Row="2"></TextBlock>   <TextBox x:Name="FirstNameTextBox" Text="{Binding Path=FirstName}" Grid.Column="0" Grid.Row="1"></TextBox> <TextBox x:Name="LastNameTextBox" Text="{Binding Path=LastName}" Grid.Column="2" Grid.Row="1"></TextBox> <TextBox x:Name="PhoneTextBox" Text="{Binding Path=Phone}" Grid.Column="0" Grid.Row="3"></TextBox> <TextBox x:Name="EmailTextBox" Text="{Binding Path=Email}" Grid.Column="2" Grid.Row="3"></TextBox> </Grid> </DataTemplate> Julian has a set of posts where he is discussing this interesting approach to composition. He's done two posts so far, but I am sure there's much more to come. Using the Presentation Model in WPF First approach to Presentation Model with DataTemplates Great stuff! Posted May 24 2008, 09:10 AM by Glenn Block with 7 comment(s) Filed under: prism, WPF

• Dispelling some urban legends about LINQ to SQL

  Scott has a great post where he dispels the following two myths about using LINQ to SQL. LINQ to SQL requires you to start with a database schema. LINQ to SQL requires your classes to implement INotifyPropertyChanged and use EntitySet<T> for any associated collections. Looking at the post I think he also added in dispelling a third legend, though he didn't explicitly call it out. LINQ to SQL requires you to use custom attributes in your code and cannot work with a simple poco.  (In other words, LINQ to SQL supports persistance ignorance!) Personally I have not used LINQ to SQL yet, though I do intend to play with it at some point. I know I have talked to many folks (including friends at Thoughtworks) and I have heard it far easier to grok and use than some other Entity frameworks :) On the intuitiveness said, I am sold. It took me about five minutes of looking at sample code to understand how to use it. Thanks for this post Scott! Posted May 18 2008, 11:26 AM by Glenn Block with 5 comment(s) Filed under: LINQ

• Guidance for developing custom solutions with SharePoint 2007.

  First let me start off by allaying all your fears, "No it's not another factory". :-)  For a while we've been hearing a lot of requests from customers for patterns & practices to deliver guidance on SharePoint. For several weeks now we've been exploring this space, and evaluating where we might be able to deliver value. With the new guidance, we want to focus on a specific set of scenarios which SharePoint is appropriate for. We then want to focus on what solution is appropriate for addressing those scenarios and why. If you've been developing SharePoint solutions, then we need your help. Please take the following survey and let us know what your pain points are, where do YOU see the most need for guidance? Posted May 18 2008, 01:48 AM by Glenn Block with 7 comment(s) Filed under: Featured, SharePoint

• Prism, CAB, and WinForms futures

  On the forums, Bil asked the questions below. Just wondering about guidance here. I have clients who are not ready or able to move to 3.5/VS2008 yet but need to start developing new Smart Client applications. They're also not ready to move to WPF as they don't see a lot of value in it for the type of apps they need. That sort of leaves me between a rock and hard place IMHO. Prism is good, but only if you're on the 3.5 platform and want to build WPF apps (right?). Smart Client Software Factory is good if you're on the 3.5 platform and want to build WinForms apps but you're tied to ObjectBuilder and CAB (and we won't open that can of worms). So what does one do when you're living in reality (2.0 platform, WinForms) and need to build new Smart Clients. Are you stuck using either the old SCSF/CAB setup or RYO. Wondering if there's any plans for Prism to be a little more broader than WPF or what the alternaties are? Thanks. Below is my answer. I hope this clarifies these questions which are on many customers' minds. Great question Bil 1. We have an FAQ we will be including in our Docs that clarifies how Prism is postioned against our other offerings. I've posted the content of that below. Let me know if it makes sense. How does Prism compare to patterns & practices’ other Composite UI offerings? Within patterns & practices, we have several offerings for building composite applications.  The following list highlights the scenarios where you should consider using each: Smart Client Software Factory: Recommended for WinForm composite application development. Mainstream recommendation for LOB applications. Leverages the most mature platform. Offers the best development and debugging experience (tooling, control support, drag & drop, RAD experience). Best for forms over data-type applications (order entry, etc). Includes guidance automation (guidance package support and recipes). Smart Client Software Factory and WPF interop: Recommended for islands of WPF in an existing SCSF application. Allows leveraging existing SCSF infrastructure. Includes guidance automation (guidance package support and recipes). WPFCAB: Recommended for migrating existing CAB applications to WPF. Pure WPF. Allows leveraging existing SCSF infrastructure, except for views. Not maintained or owned by p&p, supported by community. Literal port of CAB to WPF (not optimized for WPF paradigm). Does not include guidance automation. Prism: Recommended for building new composite WPF applications that are optimized for WPF. Targets WPF composite application development. Lighter-weight, ability to pick and choose. Better integration with existing applications and libraries. Does not include guidance automation. 2. As to what to do if your clients need to build composite UI apps, but they are not ready to move to 3.5? In terms of p&p current offerings, SCSF is the only option. Notice I said building composite UI, not smart client as SCSF on the whole is not necessarily appropriate for all smart clients. Once option is to explore using many of the Prism services in Winforms as they are NOT UI dependent (more about this in the next points). 3. On the 2.0 / Winform question, Prism libraries take hard dependencies on 3.5, not only on WPF, but also in LINQ and Lambda usage. Now most of the services do not actually depend on WPF, including Module loading, EventAggregator (currently depends on Dispatcher, but we are moving to use synchronization context). The LINQ/Lambdas could be removed. The RegionManager depends on WPF in it's use of attached properties for registering. But you can also register regions imperatively, thus allowing you to have a WinForm RegionManger that does not use attached properties. Now whether or not the guidance / libraries would be appropriate for Winforms, is a different story and one that you would have to answer. 4. Will Prism be more broader than WPF? Silverlight is definitely something we are looking at. There is already a version for Silverlight on our contrib site. Would do Winforms / Web guidance on Prism? It's possible, though not something we have thought a lot about to date. We've worked really hard to be focused, and not look outside of our main focus area that is WPF. At the same time we the design is very malleable, and loosely coupled, making it potentially usable on other platforms. Mono version of Prism anyone? Posted May 10 2008, 09:32 PM by Glenn Block with 2 comment(s) Filed under: prism

• WPF, from this to that..Wow!

  A few weeks ago, our reference implementation for Prism looked like this. Early on we decided that we needed the RI to have a better look in feel so that it delivered a more real world WPF experience. We hired a design firm to create XAML proofs based on our implementation. The process on their end was two fold. First there we a graphic designer who created non XAML proofs. Then a XAML developer converted those proofs to XAML. Once we got the proofs, Adam Calderon from Interknowlogy (on our team) team took two weeks, and merged the new XAML into our existing codebase. In the migration, there were a few aspects of the proofs that we decided not to apply because we wouldn't push on the scenarios we need to. However, the changes we did apply, did not require much code rework to the application itself. This is what came out of that effort, and what was in our last drop. I must admit, I was previously skeptical of the whole designer-developer interaction and what was really possible. I am definitely now a true believer! Great job WPF team! Posted May 08 2008, 06:44 AM by Glenn Block with 9 comment(s) Filed under: Composite WPF, Featured, prism, WPF

• Prism vs Framework XXX

  http://www.flickr.com/photos/mukluk/288925731/ There's been a bunch of talk on the net comparing Prism to other frameworks that exist. In many cases comparisons are being made based on feature parity and such. I think it's important to make the distinction of why Prism is different. Prism is a set of guidance for building Composite UI applications with WPF. It is not a framework, though it includes a light framework that was refactored out of building the guidance. This is actually a very small part of it. Here are some of the things that are different about Prism. Built with some of the leading WPF experts in the industry. Includes a reference implementation that was developed under the review of more than 25 industry experts, including several fortune 500 companies, the WPF team and the .NET product teams. Includes comprehensive documentation on building Composite UI applications, what kinds of challenges they solve, when they are appropriate, which design patterns and principles they incorporate. Includes How-Tos walking through how to implement the various composite functionality within your apps. Includes several Quickstarts designed to ease adoption, and to illustrate specific aspects of building Composite UIs. Allows customers to incrementally adopt it in their existing WPF applications rather than starting from scratch. Incorporates a Composition model that is non-invasive. Fully black-box and white-box tested. Built entirely with Test Driven Development. Full code coverage and unit test suites. This does not mean that Prism is the end-all solution, as I have said many times that is not. It does mean however that is much more than a framework with a bucket of features. We're not building it to be feature-laden, we're building it to best address a specific set of scenarios. As a friend of mine told me, "less features is a feature". Posted May 08 2008, 01:33 AM by Glenn Block with 7 comment(s) Filed under: Composite WPF, Featured, prism, WPF

• Unity and Silverlight

  It can be done! Go read Chris's post for more. Jared if you are listening, we need this for PrismContrib. (which I still need to post about) Posted May 05 2008, 05:08 PM by Glenn Block with 2 comment(s) Filed under: prism, silverlight, unity