My Technobabble

When comments are not enough.

Blog comments are great but sometimes you need that extra level of interaction. For those times, I just added this mega-cool feature all my coworkers have been telling me about. It lets you IM me directly from my blog when I am online. To use it, just click the icon you see at the top of my blog, it will show as green when I am available. All I ask is that you don't abuse it, and let me get some work done :)

If you have a blog, you can easily add this feature as well, just follow this link, log-in and enable access from the web. Then copy and paste the generated HTML where you want it.

Me + MEF = A new beginning

About three months ago, we were on the heels of shipping Prism (Composite Application Guidance). At that time, I went to Don Smith my then manager ecstatically and said "Man I just love being in p&p, this is amazing". What I meant is that I love the work we are doing, I love the way we listen to customers, I love our ability to shift our direction based on what we are hearing and I love the environment we operate in to make it happen. Prism was a prime example of that in that we changed a lot of the way we do things, and incorporated a lot of new concepts that were resonating with the community. In many ways we got back to basics. When I made that statement to Don, I imagined I'd be in p&p for years to come.

Lo and behold about two weeks after that conversation, I get an email from Brad Abrams saying we should have lunch and chat about the work going in the MEF team, and how it might be a good place for me. Initially I thought to myself, no way. It had nothing to do with MEF, but there was absolutely NO reason for me to leave, and on top of that I had a fantastic year in p&p. However, because it was Brad asking, I said I need to at least go and hear what this is about. Over the past 18 months, I had worked with Brad on many occasions and have deep respect for him.

Lunch changed everything :) As Brad described MEF, it became very clear to me that the challenges MEF is solving in many was is a framework answer to problems we've been addressing in p&p. Here was an opportunity to take those experiences and the work with the community, and  bring it to the platform. Coming to MEF raised several concerns. Can I continue being who  I am? Can  I continue pushing to try new approaches? Can I keep engaging with the community including our friends from the OSS community? Can I keep being open? Oh and can I keep being Test-Driven?

The answers Brad gave were all YES except to the test-driven part, at least not yet :) Basically he said keep doing what your doing, only do it as a member of the .NET Framework team......Too good to resist. At that moment I decided YES this is right. My wife on the other hand though I was completely nuts. She said, "You are so happy, why leave". I said "honey, you don't understand...THIS IS THE FRAMEWORK! THIS IS SCOTT GU's org." I tried to also explain to her the significance of working with luminaries like Krzysztof, Brad and Blake.  Her response "Whatever, I hope you know what you are doing"

So after several informal chats with the team, followed by an interview loop, here I am as a new PM on the MEF team, and have been for the last two weeks. Originally I wasn't planning to post yet, however yesterday I saw Hammett let the cat out of the bag about his joining us, so I thought I shouldn't wait :)

It's been a great start. This is a space I know pretty well and it is a terrific team. Because of both, the ramp up has been smooth. I've been pushing on several areas since joining. One of which is how to get more visibility in what we are doing the community. I am happy to say that as a team we've agreed to push our source to CodePlex and join our friends over in MVC land.  We've got buy in on  the team, now we just need to clear it with the lawyers :-) Regardless you'll here much more in the near feature on the work we were doing and how you can help us.

As to p&p there will always be a place in my heart. I really have had an amazing experience working with folks there. Forgetting the amazing projects we worked on, it's the people. I can't name all, so I won't name any. All I can say that it's been an amazing wild ride :)  They haven't seen the last of me, the very fact that I am working on MEF means we'll be traveling together for a long time :)

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 for building composites such as the RI. You can use this knowledge to build your own implementations even 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!

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.

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.

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!

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.

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.

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

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.

Ruby on Rails on the DLR, getting closer

Just caught this little gem from John Lam on Twitter

This is very good news.

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!

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 cod