Prism, DI, IOC


The Prism manual, in talking about DI and IOCs, references this article from MSDN Magazine.

Frustratingly, both in Chrome and IE (you would have felt Microsoft could have tried harder in eating their dog food), code listings appear like this:


Honestly, what are you supposed to make of that?

Well, once you run it through the code beautifier I’ve reference elsewhere, you can get this:

public class InvoiceService {
	private readonly AuthorizationService authoriazationService;
	private readonly InvoiceValidator invoiceValidator;
	private readonly InvoiceRepository invoiceRepository;
	public InvoiceService() {
		authoriazationService = new AuthorizationService();
		invoiceValidator = new InvoiceValidator();
		invoiceRepository = new InvoiceRepository();
	public ValidationResults Submit(Invoice invoice) {
		ValidationResults results;
		CheckPermissions(invoice, InvoiceAction.Submit);
		results = ValidateInvoice(invoice);
		return results;
	private void CheckPermissions(Invoice invoice, InvoiceAction action) {
		if (authoriazationService.IsActionAllowed(invoice, action) == false) {
			throw new SecurityException("Insufficient permissions to submit this invoice");
	private ValidationResults ValidateInvoice(Invoice invoice) {
		return invoiceValidator.Validate(invoice);
	private void SaveInvoice(Invoice invoice) {

Much better.


But Serendipity led me to this um aggregator site about fonts, and then this article specifically on handwriting-type fonts (yup). One to digest later: at its tidiest, I’d be happy to see my handwriting rendered as a font.

Later… so that Sigmund Freud font costs a bit – fair enough obviously. This site though has free fonts, including handwritten ones. Sure, you get what you pay for.Well, as we know, in Software, that is not always true, as there is a lot of great free stuff.




MEF, Herding Code

This is a nice simple trip down MEF Lane. As is this, on MSDN.

Actually, I think I prefer the MSDN one:





Key things to note from above:

The name of the concrete implementation doesn’t matter: Program is just looking to import anything that satisfies the ICalculator contract. But if in the namespace you add a second concrete implementation called eg MySimpleCalculator2,



… then you get this, or something like it:


(But if you have just the one concrete implementation matching the interface, then all is good, to reiterate that)

The article has the full detail, but we can then go on to implement the calculator to have some meaning. Add in the interfaces for IOperation and IOperationData:


Now we’ve defined those, the Calculator implementation will recognise this:


Worth repeating what MSDN says about that:

Lazy<T, TMetadata> is a type provided by MEF to hold indirect references to exports. Here, in addition to the exported object itself, you also get export metadata, or information that describes the exported object. Each Lazy<T, TMetadata> contains an IOperation object, representing an actual operation, and an IOperationData object, representing its metadata.

We define an Add implementation class for IOperation which also uses an ExportMetadata decoration to implicitly create a Symbol / + class:



Finally, there is just the Calculate method to enhance – my example assumes that the user will always enter data in the format “22(space)+(space)55”, and never make a mistake in doing that:



Do the same for subtract. Notice that there is no reference to any classes actually called add or subtract, just anything which satisfies the interface and the symbol requirement:



What happens if we haven’t defined an operator?


And finally a quick look at the _operations content:


The podcast site Herding Code manages to get in some good people. This is Rob Ashton… who seems to be pretty selfless, based on his blurb about coding for free.



Silverlight and WCF

Spent a few hours today with Laurent Bugnion’s Silverlight book, and trying to get one of his Silverlight/RIA Services examples to run. (It is a beautiful book – the use of colour in the code makes an impact.) In fact out of the box, I don’t see how it could run, as the web service contract name referenced in the client is not the same as that generated from the service. Unleashed01 But even after that, I still couldn’t get it working, defined as the catch-all error [The remote server returned an error: NotFound] There are various references to this as being a super-unhelpful message.

So I have 2 solutions running concurrently, one the service project, one the client project. In the end, in the service project, I created a Silverlight-enabled Web Service, and copied the code in the “traditional” web service sideways. I then browsed in the server to the URI, went to Service References in the Client project, created a new reference, deleted the existing one(s), rebuilt… and it worked: Unleashed02 So I don’t see how that would have worked out of the box either… but he’s obviously very good so maybe I’m wrong. Working out a WCF issue is always good for the soul. I also installed Fiddler for the first time on a home PC – what a load of rubbish we let through our home machines! Quite interesting was remembering that when you generate a service in Visual Studio, the WCF test client is pretty useful for passing calls. It even returns complex data, assuming you have some test data. Unleashed03 In fact there is little difference between the 2 service implementations other than name, so maybe it was somehow finger trouble, dunno. Unleashed04 ClientAccessPolicy – for what that’s worth… Unleashed05 Unleashed06

This msdn link is quite good on Silverlight and data access:



And although I didn’t need it in the end, xsd.exe from the Windows 8.1 SDK is pretty useful – it can take XML as input, and infer an XSD from that. Then from that, you can build classes.

Credit to this person.




MSDN data tools

Note to self to pay this site more attention – talk of schema compare could be useful.



And a section in MSDN on SQLServer unit testing.

What I really want, really really want, is to be able to test my database procedures, views etc, inside a sandbox in a build environment shared with other developers. Perhaps this article in MSDN magazine addresses it:



ICommand – there is a very good if somewhat old (so what?) step through of the principles and possible implementations on MSDN.


Trying it out on a Visual Studio App template:


This btw could be useful for MVVM stuff:


Back to the app – I really want to set up my own INPC/Observable Collection/ICommand implementation/template that I can apply to a new project and have something running within say 30 minutes. Back to the app, I said…

The generated solution gives you not a lot:


Except that StandardStyles.xaml is massive and worthy of some investigation. Create a folder and the helper class to implement ICommand (should be in its own folder or project, but anyway):


The stubbed implementation of ICommand, waiting for stuff:



Trying a naive implementation of the Execute method…


, I forgot that it is an interface – it expects an object as a parameter to Execute:



Time for bed. More tomorrow maybe – it sometimes amazes me that I do a 12 hour day at the office, and I come home, and I want to do more. Actually it’s different. Someone do the dishes for me? Thought not. BTW those people who are following me… Thanks! 🙂 I’m trying to get more of a mix of stuff, i.e. stuff not related to IT, onto the pages.. but not trying hard enough. You guys will be shocked in a good way when you say what I’ve been doing to Bamboo! No, not Wacom, I mean bamboo:


It looks alien, like Alien. But it has no answer to this…


(Cue Evil laugh.)

So accepting that this doesn’t even work:

public class SimpleCommand : ICommand {
		public bool CanExecute(object parameter) {
			throw new NotImplementedException();

		public void Execute<T>(Action<T> parameter) {
			throw new NotImplementedException();

		public event EventHandler CanExecuteChanged;

… let’s bring it back to something that at least does work. I’m creating a Console application now, set that as the startup project, reference the SimpleCommand class, and run it:

Hm, no you don’t apparently:


Hm, can’t immediately see why a  console app cannot use a reference to a Windows App. Let’s dispense with that approach then, and plug it all into a console app.


Just 2 bits then. The implementation of ICommand:




, and the program to run:


namespace ConsoleApplication1 {
	using System;
	using System.Windows.Input;

	public class SimpleCommand : ICommand {
		public bool CanExecute(object parameter) {
			if (parameter != null) {
				Console.WriteLine("[CanExecute:] Yes, you can execute)");
				return true;
			Console.WriteLine("[CanExecute:] No, you will not execute");
			return false;

		public void Execute(object action) {
			Console.WriteLine("[Execute:] [action] was [{0}]. Can I execute?", action != null ? "Not null" : "null");

			if (CanExecute(action)) {
				Console.WriteLine("[Execute:] Oh good. Apparently, I can Execute.");
			Console.WriteLine("[Execute:] Bother. Apparently, I cannot Execute.");

		public event EventHandler CanExecuteChanged;

using System;

namespace ConsoleApplication1 {
	public class Program {
		private static void Main(string[] args) {

		private static void ClickIt() {
			var o = new object();
			var simpleCommand = new SimpleCommand();



Time for a part 2, I think…