Good thing MS has exposed a set of interfaces and abstract classes in System.Web.UI for us to implement our own IHierarchicalDataSource and HierarchicalDataSourceView and IHierarchicalEnumerable and then IHierarchyData… geesh.

Data? So let’s see here, in order to bind our model to the tree control it needs to implement an interface in System.Web.UI? Well that’s just not going to happen, so its time for some Elegant Code.

Story:

Dude, as a software developer, needs to create a custom implementation of IHierarchicalDataSource, and the rest of its parts, so that he can bind a list of objects to a tree control in asp.net

• Use existing model to bind to tree control
• Must be able to reuse data source for future models
• Model must not contain a reference to System.Web.UI

In order to setup our model to address the acceptance criteria we are going to use an interface with a self-referencing generic declaration, where the type will specify itself as the concrete type. This will let us create a nice generic hierarchical model to pass into our datasource without resorting to any sort of base class.

namespace POC.Common
{
    public interface IModelWithHierarchy<T>
    {
        string Name { get; set; }
        T Parent { get; set; }
        List<T> Children { get; set; }
    }
}

The UI part of criteria is now a bit more tricky because the HierarchicalDataSourceView expects a IHierarchicalEnumerable datasource which contains IHierarchyData. Said IHierarchyData != IModelWithHierarchy<T>.  Luckily someone else has already figured this one out for us. We need an adapter.

To instantiate our HierarchyData adapter objects we will use an extension method and linq ‘Select’ to convert our datasource IEnumerable<T> of IModelWithHierarchy<T> ‘s to an IHierarchicalEnumerable of IHierarchyData.

namespace POC.Web.HierarchyExtensions
{
    public static class HierarchyConverter
    {
        public static HierarchicalModelList
            ToHierarchicalModelList<T>(this IEnumerable<T> modelWithHierarchy)
            where T : IModelWithHierarchy<T>
        {
            return new HierarchicalModelList(
                modelWithHierarchy.Select(m => new HierarchyData<T>(m) as IHierarchyData));
        }
    }
}

I am not going to bore you with the implementation details of the HierarachyData<T> adapter and the .net abstractions, but have dropped the source code here if your interested. The end result:

TreeView1.DataSource = new HierarchicalModelDataSource<Category> { DataSource = Categories };
TreeView1.DataBind();
TreeView1.CollapseAll();

Story complete! 

• Pull up object browser, set Browse to only show 3.5. (Will not work if you set to all components)
• Set the filter to ‘Show Extension Members’

• Select a type in the browser
• In the right pane you will see an ‘Extension Members’ folder
• Now you can browse the public type extensions

Before:

IEnumerable<TDomainEntity> domainEntities = Repository.Find(criteria);
IEnumerable<TDto> dtos = Assembler.DomainToService(domainEntities);
return new List<TDto>(dtos);

return Repository
           .Find(criteria)
           .ToList()
           .ConvertAll<TDto>(Assembler.DomainToService);

Lets start with the standard model for creating and firing events.

Step 1: Create the event

public eventEventHandler<EventArgs> OnLoadData;

My current method is to always use the generic EventHandler<> instead of the old-school EventHandler.  I think it makes for better-looking code IMHO.

Step 2: Fire the Event (Old Skool)

   1:  if(OnLoadData != null)
   2:  {
   3:  OnLoadData(this, null);
   4:  }

Step 3: We can do better

There is a cool feature that you get with extension methods: you can call an extension method on null base object!  So you can now do things that were impossible – like removing a null check when firing an event and just fire the event!

Step 4: Create an extension method

To start you have to create a static class and … oh forget it, here is the code.

   1:  using System;
   2:   
   3:  namespaceMyNamespace
   4:  {
   5:      public static classMyExtensions
   6:      {
   7:          public static voidFire<TEventArgs>(
                     thisEventHandler<TEventArgs> myEvent,
                     objectsender, TEventArgs e)
                     whereTEventArgs: EventArgs
   8:          {
   9:              if(myEvent != null)
  10:  myEvent(sender, e);
  11:          }
  12:      }
  13:  }

Step 5: Refactor Step 2

   1:  OnLoadData.Fire(this, null);

Done.

Step 6: Profit

Well, I will as soon as I figure out how.  I mean really, I save 3 friggen lines of code here.  Big deal–right?  Well, There are some moral victories in this. 

1. I simplified the firing of events ever so slightly by removing previously mandatory logic.
2. It is reusable.  The Fire extension method can be used with any event that we create with the generic EventHandler.
3. I have added an ever so small amount of clarity to what the code is doing.  Granted, this will only clear things up for the extreme noob or clueless manager who wants to see the code…but still. Let’s not be snobby about this.
4. I figured out a grand way to use and abuse Extension Methods in a useful way.  It makes me feel special.  What can I say.
5. And I like it.  Something about always having to check if the EventHander was null -EVERY SINGLE TIME I WANTED TO JUST FIRE A FREEKING EVENT- bugged me for some inexplicable reason.  This little hack sets my soul at ease.  So there.