Show Links

• Grigori Melnik’s Blog
• Ajoy Krishnamoorthy’s Blog
• Microsoft P&P Team Site
• Acceptance Test Engineering Guidance
• P&P Team Room Video
• P&P Upcoming Releases
• Patterns and Practices Summit, November 3-7, 2008

Download the episode MP3

The Event Broker Extension QuickStart demonstrates how you can extend the Unity container by adding a custom extension. The QuickStart implements an Event Broker for the container as a container extension and demonstrates the new extension using the StopLight QuickStart application sample.

The Event Broker Extension QuickStart contains three projects:

• EventBroker. This project implements a simple publish and subscribe mechanism that supports multiple event publishers and multiple subscribers.
• EventBrokerExtension. This project implements the custom container extension that allows applications to publish and subscribe to events using attributes or explicitly using code.
• StopLight. This project is basically the same as that described in the Unity StopLight QuickStart, but it uses the custom container extension to manage the publishing of, and subscription to, two events within the application.

Now, why is this Unity EventBroker interesting? Well, if you have ever worked with CAB (Composite UI Application Block) or SCSF (Smart Client Software Factory) then you know one of its main pillars was the implementation of a nice Pub/Sub event subscription framework which Microsoft called Event Broker. This was one of the best things about CAB. Unfortunately with CAB it is an all or nothing deal. You really cannot use the CAB Event Broker without using the rest of the CAB underpinnings.

The Unity implementation of the Event Broker is similar to CABs so you should feel right at home if you have any experience with CAB or SCSF. The one huge benefit is that the Unity Event Broker can easily be integrated into any existing WinForm or WPF application where you would like an easy to manage Event bus to handle all your event traffic.

It really is easy to implement, lets take a look at what you need to do in order to integrate the Unity based Event Broker into your application.

1) Download Unity 1.0 install it and unzip the “Unity QuickStart” package found in the Unity start menu installation path.

2) Compile the EventBrokerExtention and SimpleEventBroker projects.  Then grab the following DLLs found in the EventBrokerExtention bin folder and reference them in your application.
  EventBrokerExtension.dll
  SimpleEventBroker.dll
  Microsoft.Practices.ObjectBuilder2.dll
  Microsoft.Practices.Unity.dll

3) Now open your WinForm application and modify your entry point usually the Program.cs file which in my demo calls the FormMain.cs using a Unity Container like so.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
using EventBrokerExtension;
using Microsoft.Practices.Unity; 

namespace SampleWinApp
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false); 

            // Create parent container
            IUnityContainer mainContainer = new UnityContainer()
                  .AddNewExtension<EventBrokerBusExtension>(); 

            Application.Run(mainContainer.Resolve<FormMain>());
        }
    }
}

The important thing to notice is that I have wired up the EventBrokerExtention class through the Unity AddNewExtention method.  This will cause all the Events that are properly decorated with the correct attributes to be automatically registered in the EventBroker or SimpleEventBroker class.

You will also want to go and modified all the areas in your code where you are opening other forms to use a Unity container as well.  Here is an example opening a Form called FromA.cs 

//Create container
IUnityContainer myContainer = new UnityContainer()
           .AddNewExtension<EventBrokerBusExtension>();
//Open Form
FormA newForm = myContainer.Resolve<FormA>();
newForm.Show();

Oh, make sure you import the proper libraries on all your forms.

using Microsoft.Practices.Unity;
using EventBrokerExtension;
using SimpleEventBroker;

Now you need to setup all the Event publications and triggers. Let’s start simple, say we have a button on our FormMain that is used to force a data refresh in your application. You would need to add a publish event to your page like so.

//Using an attribute register an event in the EventBroker
[Publishes("RefreshData")]
public event EventHandler RefreshData ;
//Method you will call to trigger the event in the EventBroker 
public virtual void OnRefreshDataChange(object sender, EventArgs ea)
{
    EventHandler handlers = RefreshData ;
    if (handlers != null)
    {
        handlers(this, EventArgs.Empty);
    }
}

On your button click trigger the event like so.

private void buttonRefresh_Click(object sender, EventArgs e)
{
    //Trigger your event 
    OnRefreshDataChange(this, e);
}

Now you need to setup all your Event subscriptions, this is supper easy.  You will need to create a method on all the forms in your application that will handle your refresh command i.e. implements the functionality you wish for each form or control in your application.  So far in this contrived example I have two forms FormMain and FormA.  You would add a method like so to each page.    

[SubscribesTo("RefreshData")]
public void OnRefreshDataFired(object sender, EventArgs e)
{
         //Do something, we need to do a data refresh
}

Now anytime the RefreshData button is pushed the event is fired and all objects subscribed to that event in the EventBroker will be triggered. 

One important step you will want to do is unregister your subscribed events every time a modal form is closed.  Remember we are using the Unity IoC container to open a form which automatically registers all publisher and subscriber event handles on form_load (opened). 

// Unregister your subscription to help prevent runtime errors
private void FormA_FormClosing(object sender, FormClosingEventArgs e)
{
     EventBroker myEB = new EventBroker();
     myEB.UnregisterSubscriber("RefreshData", OnRefreshDataFired);
}

That is about it, I used this to clean up an old legacy application that had Window events thrown everywhere.  The SimpleEventBroker class has several methods you can use to monitor what is going on inside the EventBroker such as GetPublisher, GetSubscribers, etc.

Oh, in my implementation I modified the Dictionary in the SimpleEventBroker class which holds the registered published events to be static, makes it easier if you have lots of modal forms, just make sure the Keys (string values) are unique.

public class EventBroker
    {
        private static Dictionary<string, PublishedEvent> eventPublishers  

        = new Dictionary<string, PublishedEvent>();

So let me state for the record: today’s elegant code is tomorrow’s drivel.  Don’t feel bad, many writers have the same problems.  What was super amazing back in the day is now rubbish or near unreadable.  I am thinking of the Victorian writing that Hemingway usurped, and now Hemingway himself is almost unreadable (to me anyway).  Tastes change with the times.  That is a simple fact.

So what can you do about this?  As I say that old writing sucks to read (read Washington Irvine lately?), great works of literature still abound (for instance, Hemingway is still a great writer — even if I prefer Tolkien) .  So take some notes from them, and from other crafts in looking for the answer.  If you want a cliff notes version of what this is going to tell you, it is this: you must always push yourself to get better.

1. Find a good teacher.  Nothing is better than sitting at the feet of a master who can nudge you along in the right direction.  While early mistakes can often be corrected easily with a little bit of guidance, after they have had some time to fester all bets are off.  I believe a fare number of “Anit-patterns” were created by self taught developers (find SQL Ejaculation on this site). 
2. Read.   Good writer are first good readers.  Start with Code Complete, move into a good Patterns book, get MSDN Magazine, find some bloggers your like, but keep moving.  You will NEVER be done reading.  I imagine that even Martin Fowler has a “to read” booklist a mile long.
3. Read code.   There are a plethora of open source project just waiting to be read — do so.  This is the single best way to expand your coding repertoire, find things your language can do that you didn’t even know about..   Scott Hanselman has recently popularized this idea, and I thank him for it.
4. Practice.  This means writing small applications at home.  You get an idea that you want to try out — do it.  I don’t mean you have to write finished applications, just have some exploring time.  I remember talking with an 80 year old master woodworker (he lives down the street from me), who was telling me how many time he would practice making dovetail joints before he felt competent.  It was years worth.
5. Pay Attention.  Being good at anything really amounts to that.  And don’t just pay attention when reading, writing, or talking about code.  Inspiration come from everywhere, any good artist will tell you that.  Pay attention when you cook, when you work on the car, when you are wood working, playing an instrument, whatever it is that you do.  This will help you in the end, event if it is just learning the amount of dedication it really takes to become good at something.
6. Beware of preferences.  Any time I hear someone start a statement with “I prefer code to …” you know things are going downhill.  If you find someone who cares more about how your code is formatted then how it is written you have found yourself in a mess.  More importantly, beware of them in yourself.   Having code style standard is important, but it isn’t worth loosing sleep over.  This also pertains to inheritance, patterns, use of particular classes (e.g. always using the generic list class in C# when a Dictionary would be better). 
7. No Sacred Cows. Believe no single source of information.  This means not thinking that Microsoft, Sun, IBM, Richard Stallman, or anyone else will have all of the correct answers.  Apply the scientific method and do some research, experiment, and question the authority.   There should be no sacred cows in programming.
8. Talk with others.  Join a user group, show up every now and then, heckle the presenter, and -maybe- speak.  You want a broad range of people who you can talk to and bounce ideas off of.  This will help you from becoming that crazy guy in the corner who vehemently states that all your code should be in one file.  Having a mentor (mentioned earlier) is great, but having people around to push you from multiple directions is also good.
9. Learn languages.  This gets back to the “read code” idea. Make that multiple types of languages as well.  If you know C# or Java and SQL, learn Python or Ruby, get really good at JavaScript.  If you want something really out there, learn MDX.  This is also a repertoire thing.  Seeing how other languages work will make you rethink your ideas about what your current code, in whatever languages you are working in, should look like.
10. Keep Thinking!!!  That is possibly the most important point.  Keep thinking.  Don’t just evaluate something once and never return, go back and reevaluate. Did the technique work?  How could it have been better?   The idea is continual improvement.
11. Switch jobs every now and then.  When I announced I was leaving my first programming job out of college, the VP of R&D had me sit down with him and talk.  He wasn’t trying to keep me (he knew I was moving to be closer to family), he wanted to give me some advice.  He told me to change jobs every three years.  After you have been with a place for three years you have probably learned everything you are going to learn and it time to move on.  This doesn’t mean changing companies either.  I’ve been with the same company now for four years, but I’ve had three different jobs.  If you have been writing commercial applications, become a consultant – or vise-versa, become a test engineer, expand your boundaries.  Again, this is about pushing yourself to be better.
12. Have a Hobby. But don’t ask about me, I have too many.   Creating software is about creating things.  So I suggest picking a hobby that involves creating something.  Popular hobbies amongst programmers I know include: cooking, music, woodworking, beer making, and BBQ (which is different than cooking).  But don’t discount sports (golf is always popular), computer games, and board games.  Anything that promotes the development of skill levels can’t be a bad thing.

And I’m stopping there.  This is my beginner’s guide to how to become the writer elegant code.  If you have others you think I missed, add them too the comments.

Matt is an amazing presenter and fount of knowledge on WCF, WF, and BizTalk. He drops some great knowledge on these subjects and enterprise SOA, along with some discussion of Oslo, Microsoft’s new Model Driven initiative.

• PluralSight
• Matt’s Blog
• Oslo
• Windows Communication Foundation
• Windows Workflow
• Microsoft BizTalk

Download the episode MP3

I am sure everyone will be blogging about all the great sessions they attended at code camp. I enjoyed all of the presentations I attended, and I am excited to explore some new material.

I want to share a few thoughts on my presentation dealing with Model-View-Presenter in ASP.NET after listening to Scott Hanselman’s session on the ASP.NET MVC Project. I may have the percentage incorrect, but Scott mentioned something like it is predicted that only 10% of the ASP.NET community currently using Web Forms will adopt and use the MVC framework. The MVC framework is an addition to ASP.NET, it is not a replacement. What this means is that Model-View-Presenter will still be a viable pattern to implement with your ASP.NET applications, and it is not going away. ASP.NET Web Forms will not be going away either.

Use MVP to get your third party controls under test. Use MVP to provide that separation of concerns in your legacy applications. Use it entirely or in conjunction with the MVC framework. It is all about testability. Glenn Block presented on the Web Client Software Factory, and what pattern does this implement? Model-View-Presenter.

I am providing my presentation and source code (3.67 MB) from my talk on MVP. It will be available via the Boise Code Camp site as well.

Again, thank the many individuals and their families who sacrificed their time to bring to the local community this years code camp.

Around the office’s water cooler on Monday, I will be able to say, "and this one time, at code camp…"

He also gives us a glimpse of what it is like to live your life visiting other people’s development shops. Did you know source control is stil optional in some organizations?

Chris is a true code craftsman and this shows in his clear explanations of some very advanced programming concepts. If you haven’t played with Lambda expressions, anonymous delegates, or LINQ, start with this podcast.

Download the episode MP3

If you are looking for a similar product with a longer lineage, you could look up: StructureMap, Spring.Net, and Castle Windsor.  StructureMap is maintained by Jeremy Miller, who is a favorite blogger of mine (everyone should read his series on Build your own CAB).  Spring.Net is a port of an existing Java project, and Castle Windsor seems to have a lot of mind share.  Currently, Spring.Net is the only IoC library that I have used.

OK, definitions:
IoC: Inversion of Control, also called Dependency Injection.
This is based on a pattern found in the Gang Of Four books on Design Patterns.
You can read more about this pattern at Martin Fowlers web site:
http://martinfowler.com/articles/injection.html
Or on Wikipedia:
http://en.wikipedia.org/wiki/Inversion_of_control

The basic principle that IoC is used for is Loose Coupling.  If you have a multi-layered application, each layer should not have to know specific details about the other layers.  So each object in a specific layer will implement an interface that the IoC provider knows about.  Then, when a specific dependency is needed, you ask the IoC container for it (note: the IoC container is Tightly coupled) for the object to do the work.   If you look at the Asp.Net Membership Provider, you can see a simple example of that at work.

One of the ways that this can help you is that now all of your middle pieces can be swapped out without having to make massive code changes.  This also makes testing easier, as now you can more easily stub/mock/fake dependencies and just test your application logic.

Also, if you really get into the whole IoC thing, you will find that there are a number of other cool Computer Sciency things are possible.  Like Aspect Oriented Programming (unknown if Unity supports that or not).

Now with all of the other IoC libraries out there, why would I like the fact that Microsoft has created their own? 
One of the current issues with a lot of Microsoft software, especially the samples, is that they are all VERY tightly coupled (again, tight coupling is not good), but it is a pain to get around without an IoC solution.  And, as per Microsoft’s own structure, they will not use any software that they didn’t write or own.   So I’m hopeful that now they can start producing some software with loose coupling in mind, and make all of our lives easier.

All right, there are still a lot of definitions and ideas that could leave you puzzled, that happens.  That is also why we have google.  If you see something you don’t understand, leave a comment and I’ll try to clarify, or point you to someone else with a better explanation than I can give.

Finally, if you are looking for more information on this sort of thing, check out the session on Castle Windsor at Boise Code Camp on March 8.

For the most part the Bundle rocks, but there are a few things which didn’t meet our needs:

1. The default PropertyProxyValidator inherits from System.Web.UI.WebControls.BaseValidator, like the other Asp.Net validators. This makes it great for mixing all types of standard Validators (Like Regex or RequiredField), but has a major drawback for Client side validation because it validates on every PostBack (full) as well as Callback (partial).
2. On a full postback, such as a form submit, the ServerSideValidationExtender issues a Callback request to the Validator
3. Even if the value had not changed, validation still occurs.

A simple scenario

We have an Organization with two fields, Name & Code

Lets look at the validation events:

• Enter Name ‘Bob’s Plumbing’, Press Tab (or click off)
  • Callback: Validation occurs for Name
• Enter Code ‘BPL’, Press Tab (or click off)
  • Callback: Validation occurs for Code
• Click Save
  • Callback: Validation occurs for Name
  • Callback: Validation occurs for Code
  • Postback (full): Validation Occurs for Name & Code

So we have validated each property 3 times. This might be OK we were just parsing for special characters, but in our case we also want to call a service and see if these values already exist in our system: 3x is too expensive.

Aside from being expensive, this is a unique type of validation where we want to check if a condition isn’t true (Org Name doesn’t exist) vs. is true. (an valid email address or a valid state)

This makes point #3 above especially troubling for our scenario, because if we want to edit this Organization in the future, any time we change a value, all the rest of the validators will fire and come back invalid as they already exist.

Example updating just the Org Code, which causes the Name to validate:

The Solution

• Kill the full postback validation with OnCallBackPropertyProxyValidator
• Modify ServerSideValidationExtender to *only* validate if the value has changed

OnCallBackPropertyProxyValidator

OnCallBackPropertyProxyValidator is a pretty quick fix. We will just inherit the ProperyProxyValidator and kick out of the EvaluateIsValid method if its not a CallBack.

   1:    /// <summary>

   2:    /// Class which only performs validation when page is in a callback state

   3:    /// </summary>

   4:    public class OnCallBackPropertyProxyValidator : PropertyProxyValidator

   5:    {

   6:        /// <summary>

   7:        /// If Page.IsCallBack, determines whether the content in the input control is valid.

   8:        /// </summary>

   9:        /// <returns><see langword="true"/> if the control is valid; otherwise, <see langword="false"/>.</returns>

  10:        protected override bool EvaluateIsValid()

  11:        {

  12:            if (!this.Page.IsCallback)

  13:            {

  14:                this.ErrorMessage = "";

  15:                return true;

  16:            }

  17:            else 

  18:            {

  19:                return base.EvaluateIsValid();

  20:            }

  21:        }

  22:    }

ServerSideValidation

Well add the ‘only-validate-if-value-changed’ functionality by fetching the current text value from the control to be validated, storing the property in JSON, and then evaluating if the value has changed before requesting validation from the server.

Modifying the ServerSideValidationExtender.cs

Add the CurrentValue Property to the Extender C# class:

   1: [ExtenderControlProperty]

   2: [ClientPropertyName("currentValue")]

   3: [DefaultValue("")]

   4: public string CurrentValue

   5: {

   6:     get { return GetPropertyValue<string>("CurrentValue", string.Empty); }

   7:     set { SetPropertyValue<string>("CurrentValue", value); }

   8: }

Set the current value in OnPreRender:

   1: protected override void OnPreRender(EventArgs e)

   2:     {

   3:         base.OnPreRender(e);

   4:        

   5:         Omitted code here....        

   6:  

   7:         // Set the current Text value

   8:         Control controlToValidate = extendedValidator.NamingContainer.FindControl(extendedValidator.ControlToValidate);

   9:         ITextControl textControl = controlToValidate as ITextControl;

  10:         if (textControl != null)

  11:         {

  12:             CurrentValue = textControl.Text;

  13:         }

  14:         

  15:         Omitted code here...

  16:     }

Modifying the ServerSideValidationBehavior.js Behavior

Add the CurrentValue property to the descriptor:

   1: AjaxControlToolkit.WCSFExtensions.ServerSideValidationBehavior.descriptor = {

   2:    properties: [   {name: 'callbackControl', type: String},

   3:                    {name: 'validateEmptyText', type: Boolean},

   4:                    {name: 'currentValue', type: String} ]

   5: }

Add the accessor methods to the prototype:

   1: get_currentValue: function(){

   2:     return this.currentValue;

   3: },

   4: set_currentValue: function(value){

   5:     this.currentValue = value;

   6: }

And finally check to see if the value has changed

   1: Validate: function() {

   2:     var valueToValidate = this._getValueToValidate();

   3:  

   4:     Omitted....

   5:  

   6:     if (valueToValidate === this.get_currentValue()) {

   7:         return true;

   8:     }

   9:     

  10:     Omitted.... 

  11:     

  12: },

And that’s it. What we end up with is client side validation which only occurs when the value is changed on the client, through a callback, and no where else. All other validation works in tandem as expected, such as the standard ASP.NET validators, PropertyProxyValidator, or a custom validator which performs VAB self validation.

Though the Bundle didn’t do everything we were looking for right out of the box, it was pretty easy to get in there and make work exactly how we wanted. Hats off to P&P for some great guidance.

The source code is here. Its just the files, not a complete working solution, but if you download the WCSF source/ Validation Bundle you should be able to plug it in fairly easily.

Following the MVC talk, Martin Danner will be doing an hour or so on the fresh new features found in Team Foundation Server 2008.

I hope to see you there. Let’s go for a beer after over at Table Rock!

One thing that makes testing a little difficult is the fact there is no dependency injection (DI) model built into the current CTP. A recent post by Phil Haack may lead one to speculate that a solution is in the works. A dependency injection model coupled with MVC lets us mock our models and views in more declarative ways.

Instead of waiting for a DI technology, we can use a little elbow grease and roll a pseudo  workable pattern ourselves. How can we mock the model? How about this?

1. Use an interface to define your model. Remember? Like you’re supposed to?

   1: namespace MvcApplication.Models

   2: {

   3:     public interface INWStore

   4:     {

   5:         List<Category> GetCategories();

   6:         

   7:         Category GetCategory(int categoryId);

   8:  

   9:         List<Product> GetProducts(int categoryID);

  10:  

  11:         Product GetProduct(int id);

  12:     }

  13: }

2. Add a constructor to your controller that takes an instance of the interface as an argument. With your default constructor, just instantiate the internal member.

   1: namespace MvcApplication.Controllers

   2: {

   3:     public class BaseDataController : Controller

   4:     {

   5:         INWStore _dbContext;

   6:  

   7:         public BaseDataController()

   8:         {

   9:             _dbContext = new NWStoreDataContext();

  10:         }

  11:  

  12:         public BaseDataController(INWStore dataContext)

  13:         {

  14:             _dbContext = dataContext;

  15:         }

  16:     }

  17: }

3. Mock the model in your unit test and pass it in as an argument to the controller constructor. The MVC framework will use the other constructor.

That’s all there is to it. This isn’t new thinking, just a reminder. I was walking through all of the examples and lost sight of this for a little while.

I agree with the MVP debaters that a nicer way to mock the views would be to pass them in as interfaces like we just did to the model, but the solutions being demonstrated by Haack are viable as well.