Friday 10 August 2012

Using Reflection to Force Evaluation of Parameterized Static Methods on Controls without requiring an Instance to be Loaded

At my current Telecommunications client, we have been using EpiServer CMS and associated frameworks (essentially ASP.NET webforms) to develop their website.

We have the concept of "Accordion" controls which are essentially a group of user controls sitting inside an ASP.NET repeater that are loaded based on CMS configuration settings. The user controls are only loaded when the user clicks to expand one of these accordions.

This presented a problem because we wanted to access settings and properties of those user controls to determine whether to display the title outside the user control or not (before any of those user controls were loaded).

I initially thought of using events and delegates - but that wouldn't work because they would require us to spin up instances the controls to get those to fire (not ideal).

Instead of this, we used a nice trick (thanks Marcus for the idea) with reflection which calls a static method on each of those user controls. Any instance objects we needed to use in the static class, we just passed in as a parameter to our User control's method.

This meant that we could use reflection on the static method for each of our user controls - and it would return to use whether we should hide or show the title for that control. We put the type name in the CMS so it would know what user control type and method it should Invoke (without even loading the control). To easly allow instances our dependency-injected controllers to be called from this static method, we just passed them in as parameters to the static method as below:

A code snippet of the meat of the method is as below:

        public static bool GetIsAccordionAndTitleVisible(string typeName, IServiceController serviceController)
            var type = Type.GetType(typeName);

            if (type != null)
                var result = true;
                System.Reflection.MethodInfo mi = type.GetMethod("GetIsControlTitleVisible");
                if (mi != null)
                    var p = new object[1]; //Invoke requires object array for parameters
                    p[0] = serviceController;
                    result = (bool) mi.Invoke(null, p);
                return result;
            return true; //Default=true.

In this way, we can defer logic to user controls that haven't even been loaded yet. We could have also used our Registry to access our dependency-injected service controller as an alternative to the IServiceController parameter on GetIsControlTitleVisible()

Friday 3 August 2012

Preferred Microsoft technologies for creating a Lightweight Service Bus - creating RESTful Services with the ASP.NET Web API

I'm starting with a new banking client next week and I thought it was time to make sure all my preferred technology choices are still the latest and greatest on the block.

This ongoing technology-revalidation process should be par for the course for any technology-based consultant. This is especially considering software framework release cycles of players like Microsoft have shortened from years to months.

One of the core components of this work for my new client is the development of a lightweight ESB as a "Clayton's" SOA layer (e.g. with limited discoverability). One of the key aims is towards optimising performance.

Obviously REST is the flavour of the moment as all the largest sites in the world (e.g. Twitter and Facebook) are fully on board with it. It is also the most performant and platform-agnostic approach to exposing services. I had to interact with Twitter heavily via REST for my previous client (a large media company).

Naturally, I would prefer to be creating RESTful services and returning JSON (or optionally XML) just like the largest sites in the world are doing in their APIs.

Windows Communication Foundation (WCF) is the preeminent technology in Microsoft .NET for producing web services. However, I found out that a few months ago, there was a complete consolidation of the leading frameworks for RESTful service creation in .NET:

"For several years now the WCF team has been working on adding support for REST. This resulted in several flavors of REST support in WCF: WCF WebHTTP, WCF REST Starter Kit, and then finally WCF Web API. In parallel the ASP.NET MVC team shipped support for building basic web APIs by returning JSON data from a controller. Having multiple ways to do REST at Microsoft was confusing and forced our customers to choose between two partial solutions. So, several months ago the WCF and ASP.NET teams were merged together and tasked with creating a single integrated web API framework. The result is ASP.NET Web API."

To this end, you should be considering first and foremost the ASP.NET Web API for your RESTful Service creation needs. For more details, see

For consumption of those RESTful services via the available client-side frameworks? Well that's another blog post altogether!

Till next time,