At compile time I don’t know which methods are going to be called so I have to invoke them at runtime. The most obvious way to do that is to use the reflection API of .NET to do a late bound method call. Although, IMHO, this is a perfectly valid solution to this problem it isn’t exactly fast.

System.Reflection.Emit.DynamicMethod is a better alternative for late bound method invocation when it comes to performance. Although it requires you to write Intermediate Language (IL) it is actually quite easy to use.

Let me first show you an example:

public class Program
{
public delegate void SayHello(string name);

public static void Main(string[] args)
{
var sayHelloMethod = BakeHelloMethod();
sayHelloMethod("Trilobyte");
}

public static SayHello BakeHelloMethod()
{
// get the System.Console.Write method
Type consoleType = typeof (Console);
MethodInfo writeMethodInfo = consoleType.GetMethod("Write", new[] {typeof (string)});

// create a new dynamic method with return type void and one argument of type string and get its IL generator
var dynamicMethod = new DynamicMethod(string.Empty, typeof (void), new[] {typeof (string)});
ILGenerator methodGenerator = dynamicMethod.GetILGenerator();

// first write 'Hello, '
methodGenerator.Emit(OpCodes.Ldstr, "Hello, ");
methodGenerator.Emit(OpCodes.Call, writeMethodInfo);

// next write the name which is the first argument
methodGenerator.Emit(OpCodes.Ldarg_0);
methodGenerator.Emit(OpCodes.Call, writeMethodInfo);

// finish the method
methodGenerator.Emit(OpCodes.Ret);

// create a delegate to the method we just created
return (SayHello)dynamicMethod.CreateDelegate(typeof (SayHello));
}
}

Creating a late bound method call using DynamicMethod isn’t as complex as you might think. It only took 10 lines of code to generate a functional method. The only difficult part is baking the IL yourself, but you can use tool like Reflector to decompile C# code and see how it works in IL.

Although I don’t use IL very often, maybe once a year, I still find it a useful tool to optimize performance of applications and I recommend to invest some time in learning the basics because it gives you a great insight in how the CLR actually works.

Cheers!

WTL PictureBox

WTL Resourceless Dialog Toolkit

You can also find these articles on the CodeProject and CodeGuru.

Take a look at the UML diagram below; you will notice that there are actually two flows:

• One synchronous, which guides the user trough the payment screen
• One asynchronous, which notifies when the payment state changed (payment is confirmed or canceled)

Synchronous flow

A said: the synchronous flow guides the user through the confirmation, payment and thank you steps. The following steps are taken:

1. A record is created to track the status of the payment for the order that is being made.
2. The user is redirected to the payment provider page, this can be done using various methods including HTTP GET and HTTP POST. One of the parameters is the ID of the payment record. The other parameters depend on the PSP and might include a message signature, a merchant ID or a redirect URL for example.
3. The user fills in his credit card information, IDEAL information or any other payment information supported by the PSP. Once the user has filled in that info, the PSP processes the payment and redirects the user back to the web shop application, usually with some confirmation information, like: status (failed, in processes) and a transaction ID, in the parameters.
4. The web application stores the transaction ID in the payment record and shows the thank you text to the user.

That is it for the synchronous flow.

Asynchronous flow

The asynchronous flow, often called notification flow, is used to give the web shop status updates about the payments. This asynchronous flow is needed because a payment might take several days or even weeks to complete. For instance: when a user pays by transferring money into a designated bank account he/she usually has two weeks to do so. The asynchronous flow can be initiated by either the PSP or the web shop depending on the specific PSP implementation.

The single purpose of the asynchronous flow is to update the payment identified by either the payment ID (generated by the web shop) or the transaction ID (generated by the PSP). Once a payment status has been updated the asynchronous flow could send a mail to the user to inform him/her that the payment is complete.

Conclusion

Although the implementation specifics vary between PSP, the general flow as described above is pretty consistent for PSPs. I hope you can integrate a PSP with your web shop in the same way, if not please let me now: this pattern needs a revision.

Here is an overview of the articles I have written:

1. Introduction to Lucene
2. Indexing basics
3. Search basics
4. Alternatives ( did you mean …)
5. Faceted search / Drill down
6. Class reference

Cheers!

Here is my implementation:

private static readonly byte[] _bitsSetArray256 = new byte[] { 0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4, 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 4, 5, 5, 6, 5, 6, 6, 7, 5, 6, 6, 7, 6, 7, 7, 8 };

public static int GetCardinality( BitArray bitArray )
{
var array = (uint[]) bitArray.GetType().GetField( "m_array", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance ).GetValue( bitArray );
int count = 0;

for ( int index = 0; index < array.Length; index ++ )
{
count += _bitsSetArray256[ array[ index ] & 0xFF ] + _bitsSetArray256[ ( array[ index ] >> 8 ) & 0xFF ] + _bitsSetArray256[ ( array[ index ] >> 16 ) & 0xFF ] + _bitsSetArray256[ ( array[ index ] >> 24 ) & 0xFF ];
}

return count;
}

The reflection access to the private field of BitArray isn’t exactly fast, but I will optimize it later and post the updated snippet right here.

I hope this implementation is as useful for you as it is for me.

For now, I am thinking about the following articles:

1. Introduction to Lucene
2. Indexing basics
3. Search basics
4. Alternatives ( did you mean …)
5. Faceted search / Drill down
6. Class reference

Let met know if you have got more ideas for articles.

For my work at Liones I am writing a technical design for a shopping cart. The requirements are fairly basic, except for one: the shopping cart must be generic to support any payment service provider (psp) and customer relationship management (CRM) system. Also there might be several different product types in the future, like: subscriptions, downloads, pay per use, etc.. These requirements make the shop very complex and a great challenge.

I started with an investigation on the internet about this subject and I quickly found out that there aren’t much articles on this topic around, but I found a few very interesting ones though. Next I started to draw some UML diagrams; I added some best practices like the Money class.

Then it got interesting: Yvonne (a colleague, senior/lead developer) and I were going over my conceptual model and we were adding and shifting responsibilities as we were going. Things went rapid from that point on: object came to the surface, responsibilities were put on the right place and the domain model started to reveal itself.

The next thing we did was to group objects into packages and again there was some debate about in which package we would put certain objects and what the dependencies between the packages were. The debates made the domain model even clearer. We came up with the following packages:

• Product Catalog (Product information and grouping)
• Cart (The actual cart)
• Payment Service (Encapsulation of different payment service providers)
• CRM (synchronization with back office)
• User (User & Profile)

I am not going to discuss the packages in detail here because that is not the scope of this post.

Once we wrapped up that session, I drew the new UML diagrams (in Sparx Enterprise Architect). I made some minor refinements in the model and I set up a meeting with Yvonne and Gjalt (another colleague, architect) to review the technical design.

As the review session went on, we made a few minor refinements on the design and discussed how certain parts could be implemented. There was one major element that wasn’t clear: how does the coupling with a payment service provider work? There seem to be 2 categories: synchronous payments and asynchronous payments.

That is where we stand now, we brainstormed on how to tackle the payment problems but that is for part 2!

The problem: Coupling my views (WPF) to my domain model (C#).

The solution I came up with back then is to make the domain model aware of the need to bind and implement specific functionality like [System.ComponentModel.INotifyPropertyChanged]. By doing this I cluttered my domain model with non domain model code, which made the model difficult to understand and maintain, basically: No Go!

The solution: Model-View-ViewModel pattern

I went out looking for pattern that could help me to eliminate this code cluttering. After doing some research using my favorite search engine I discovered that there was a pattern for this problem: Model – View – ViewModel (MVVM or M-V-VM).

This pattern basically says: just wrap your domain model in another model, the view model, and implement view specific logic (like: INotifyPropertyChanged) on that view model.

I also implemented my commands on this view model class, I could have factored it out to view controllers but I didn’t see the need for that right now.

For the implementation of the commands I choose the solutions suggested by [Karl on WPF] and [Josh Smith]: the RelayCommand class. The purpose of this class is to drastically reduce the number of command needed by providing a single class which takes a delegate to execute the actual command. It also contains some logic to hook into the WPF command infrastructure.

Here is my implementation of the RelayCommand in C#:

public class RelayCommand: ICommand
{
	private readonly Predicate<object> canExecuteMethod;
	private readonly Action</object><object> executeMethod;
	public RelayCommand(Action</object><object> executeMethod): this(executeMethod, null) {}

	public RelayCommand(Action</object><object> executeMethod, Predicate</object><object> canExecuteMethod)
	{
		// validate argument
		if (executeMethod == null)
			throw new ArgumentNullException("executeMethod");

		// set values
		this.executeMethod = executeMethod;
		this.canExecuteMethod = canExecuteMethod;
	}
	#region ICommand Members
	///<summary>
	///Occurs when changes occur that affect whether or not the command can execute.
	///</summary>
	public event EventHandler CanExecuteChanged
	{
		add
		{
			if (canExecuteMethod != null)
				CommandManager.RequerySuggested += value;
		}
		remove
		{
			if (canExecuteMethod != null)
				CommandManager.RequerySuggested -= value;
		}
	}
	/// <summary>
	/// Defines the method to be called when the command is invoked.
	/// </summary>
	/// <param name="parameter">Data used by the command.  If the command does not require data to be passed, this object can be set to null.</param>
	public void Execute(object parameter)
	{
		executeMethod(parameter);
	}
	/// <summary>
	/// Defines the method that determines whether the command can execute in its current state.
	/// </summary>
	/// <returns>
	/// true if this command can be executed; otherwise, false.
	/// </returns>
	/// <param name="parameter">Data used by the command.  If the command does not require data to be passed, this object can be set to null.</param>
	public bool CanExecute(object parameter)
	{
		return canExecuteMethod == null ? true : canExecuteMethod(parameter);
	}
	#endregion
	public void RaiseCanExecuteChanged(EventArgs e)
	{
		CommandManager.InvalidateRequerySuggested();
	}
}

public class RelayCommand<t>: ICommand
{
	private readonly Predicate</t><t> canExecuteMethod;
	private readonly Action</t><t> executeMethod;
	public RelayCommand(Action</t><t> executeMethod): this(executeMethod, null) {}

	public RelayCommand(Action</t><t> executeMethod, Predicate</t><t> canExecuteMethod)
	{
		// validate argument
		if (executeMethod == null)
			throw new ArgumentNullException("executeMethod");

		// set values
		this.executeMethod = executeMethod;
		this.canExecuteMethod = canExecuteMethod;
	}
	#region ICommand Members
	///<summary>
	///Occurs when changes occur that affect whether or not the command can execute.
	///</summary>
	public event EventHandler CanExecuteChanged
	{
		add
		{
			if (canExecuteMethod != null)
				CommandManager.RequerySuggested += value;
		}
		remove
		{
			if (canExecuteMethod != null)
				CommandManager.RequerySuggested -= value;
		}
	}

	/// <summary>
	/// Defines the method to be called when the command is invoked.
	/// </summary>
	/// <param name="parameter">Data used by the command.  If the command does not require data to be passed, this object can be set to null.</param>
	public void Execute(object parameter)
	{
		executeMethod((T)parameter);
	}
	/// <summary>
	/// Defines the method that determines whether the command can execute in its current state.
	/// </summary>
	/// <returns>
	/// true if this command can be executed; otherwise, false.
	/// </returns>
	/// <param name="parameter">Data used by the command.  If the command does not require data to be passed, this object can be set to null.</param>
	public bool CanExecute(object parameter)
	{
		return canExecuteMethod == null ? true : canExecuteMethod((T)parameter);
	}
	#endregion
	public void RaiseCanExecuteChanged(EventArgs e)
	{
		CommandManager.InvalidateRequerySuggested();
	}
}

Conclusion

The MVVM pattern is a great pattern which allows you to separate the WPF view from your domain model, preventing code cluttering. I recommend every WPF or Silverlight developer to look into this pattern and use it when you encounter the same problem I had.

References:

http://karlshifflett.wordpress.com/mvvm/

http://joshsmithonwpf.wordpress.com/category/mvvm/

The truth, however, is that everyone is responsible for their own actions. As developers we should provide solutions instead of excuses. Of course we are allowed to make mistakes or an error in judgment, but we have to admit that honestly and try to offer options.

We can blame clients, project leaders, our lead developers, our architects, our office manager or that new trainee but in the end you, and only you, are responsible for your own work.

So next time you think about making up an excuse, think about solutions first. You will sound smarter that as a matter of a fact you will be smarter!

While thinking about those requirements I quickly thought of a concept I saw in Python: Try to call find a callable method, otherwise do the default action. In Python you can use ‘getattr(…)’ to get a possible method of a class and with ‘callable(…)’ you can check if the method is actually a method.

You get something like this on your dispatcher object:

def Dispatch(self, methodName, arguments=None)
   method = getattr(self, methodName, None)
   if callable( method ): method( arguments )

I implemented this extensible architecture in exactly the same way. It was fairly easy to do, painless and it is extensible.

Learning multiple programming languages/concepts pay off!