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.

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/

Test-Driven Development [1] werkt als volgt:
Elke iteratie begint met het schrijven van een geautomatiseerde test, vaak unit test genoemd. De ontwikkelaar schrijft deze test op basis van de specificaties en eisen van de te ontwikkelen functionaliteit. De test controleert dus of de geschreven implementatie van de functionaliteit correct is. Vervolgens voert de ontwikkelaar de test uit om deze te laten falen, aangegeven door een rood licht, omdat er nog geen implementatie code is geschreven.

Nu de ontwikkelaar weet dat de test goed functioneert kan hij beginnen met de eigenlijke implementatie van de functionaliteit. Waarneer de implementatie voltooid is kan de ontwikkelaar de geschreven code testen door de test weer uit te voeren, en deze keer, mits de implementatie goed geschreven is, zal de test slagen en een groen licht geven. De ontwikkelaar kan nu met zekerheid zeggen dat de code werkt volgens de specificaties en eisen. Voor een uitgebreidere en correctere uitleg: Bron [1].

Het “Just Say Thanks” patroon [2] gaat over het oprecht bedanken van mensen voor hun inspanning hoe onbetekenend die ook mag lijken. Iedereen vind het immers leuk om gerespecteerd te worden. Dit patroon heb ik leren kennen over een boek dat gaat over veranderingen en ideeën binnen een bedrijf: “Fearless Change” [3] van Mary Lynn Manns en Linda Rising.

Test-Driven Development maakt eigenlijk gebruik van het “Just Say Thanks” patroon, en wel om de volgende reden: Eerst schrijf je een geautomatiseerde test, vervolgens voer je die test uit. De test zal niet slagen, en een rood licht geven, omdat er nog geen implementatie code geschreven is. Vervolgens schrijf je de implementatie code en voer je de test nogmaals uit. Deze keer zal, indien de implementatie goed geschreven is, de test slagen en krijg je een groen licht te zien. Dat groene licht is een metafoor voor iemand die tegen je zegt:

Je hebt goed werk afgeleverd. Oftewel het “Just Say Thanks” patroon.

Als laatste wil ik opmerken dat het Just Say Thanks patroon in het dagelijkse leven veel vaker gebruikt zou moeten worden. Het kost niks om iemand even te bedanken, maar het zal die andere persoon een goed gevoel geven en dat weer naar jou reflecteren. Toegegeven, ik pas het patroon ook lang niet altijd toe, maar verscheidende keren dat ik het gebruikt heb kreeg ik een positieve reactie! Ik kan het iedereen aanraden om het te proberen.

Bedankt voor de aandacht,
Bert Willems