You might have come across the phrases IoC, Dependency Injection, Mocking among others, these are commonly used when talking about “Inversion Of Control” which is the full meaning of the abbreviation IoC. So what is this “IoC” that everyone is talking about?
Inversion of control is a principle in Software Engineering, let’s just take a look at the Wikipedia definition of this
In practice, Inversion of Control is a style of software construction where reusable generic code controls the execution of problem-specific code. It carries the strong connotation that the reusable code and the problem-specific code are developed independently, which often results in a single integrated application.
Rather than explaining the text below, let me show an example of an application that does not follow this principle, but will when we’re done here! I’ve got a solution prepared that looks like this:
This solution simulates an order process, where we’ve got a window where we can place some kind of order and then we’ve got some sort of payment provider that executes the order request. This is the only content so far in the InversionOfControl.Payment library:
public enum PaymentResult
{
Success,
Failure
}
public class PayPalPaymentProvider
{
public PaymentResult Execute(string paymentData)
{
if (string.IsNullOrEmpty(paymentData)) return PaymentResult.Failure;
return PaymentResult.Success;
}
}
All we’re doing is to check if the data we send into the execute method actually contains any information at all, if it doesn’t we return a failure result, otherwise we return a success result. Keep in mind that when you implement communication with real payment providers, there are a lot more code to it. But let’s keep the example clean!
The order form is very simple and looks like this:
When we press the button this is what’s going to happen:
private void ProcessOrderClick
(object sender, EventArgs e
)
{
ProcessPayment
(orderInformation
.Text);
}
public void ProcessPayment
(string orderData
)
{
var paymentProvider
= new PayPalPaymentProvider
();
var result
= paymentProvider
.Execute(orderData
);
MessageBox
.Show(result
.ToString());
} So far we’ve got our order form where we can place an order, when we place the order we execute our order placement and directly communicate with our payment provider. Let’s call this Step 1, we’ve set up the project and we can execute a payment, you can download the code here, unzip it and look in the folder named Step 1. You can also browse the code on github.
Let’s bring up another one of those commonly used abbreviations; TDD or Test After Development. Payments are a great example of something that really needs to be tested thoroughly and you can’t have any errors here. Because either it will be expensive for you, your customer or the end user, no matter which one, you’ve got a big problem.
But what happens when we introduce testing at this stage? How do we actually test the entire flow of the application without communicating directly with payment provider? This is where Inversion of Control and Dependency Injection comes into play. Dependency Injection is a design pattern with the following Wikipedia explanation
DI whose purpose is to improve testability of, and simplify deployment of components in large software systems.
The pattern involves some rules that we need to adapt to, which basically means we have to write cleaner and more testable code. In order to make our code cleaner and more testable we need to break some of the static parts out, this being the actual instantiation of a concrete type in the payment processing.
Take a look at this line of code:
var paymentProvider
= new PayPalPaymentProvider
();There’s something “wrong” with it; We’re instantiation the concrete type here! To make the method testable, we don’t want that because this means that it will always use our real payment provider information and execute the order against it, which can make the testing expensive for the tester ( if he has to provide is credit card number all the time that is! ).
The easiest way to break it out is to move this to the method argument list, which means that instead of creating an instance in the method, we want someone else to inject it to us. Let’s look at this in a two-step refactoring, first we move the declaration outside of the context and change the method signature:
public void ProcessPayment(string orderData, PayPalPaymentProvider paymentProvider)
{
var result = paymentProvider.Execute(orderData);
MessageBox.Show(result.ToString());
}
This will let us create an instance of PayPalPaymentProvider before we call the processing method and inject it when we call the method. But we are still working with the concrete type, so let’s take a look at the next step in the two-way refactor, let’s simply it to an interface!
All the interface need to tell us is that we’ve got a method called Execute that will return a result to us, so we simply declare it like this:
public interface IPaymentProvider
{
PaymentResult Execute(string paymentData);
}
And then we need to tell our payment provider to actually implement the interface, all we need to change is the class signature:
public class PayPalPaymentProvider : IPaymentProvider
So far so good!
Now we just need to change the method signature for our payment processing as well and we are all set for some DI!
public void ProcessPayment(string orderData, IPaymentProvider paymentProvider)
Now when we want to process the payment when we execute the order, the event handler will look like this instead:
private void ProcessOrderClick
(object sender, EventArgs e
)
{
var paymentProvider
= new PayPalPaymentProvider
();
ProcessPayment
(orderInformation
.Text, paymentProvider
);
} By the looks of it, we now have a simple and elegant way to process our payments, let’s create a test project and reference to InversionOfControl.Demo. Now create a test called PaymentTests.
So how do we start testing the payment processing?
We only have one concrete payment provider at the moment and this one we don’t want to use for our unit testing, so what we will do instead is that we will create a fake class that will act as the real payment provider, this is dependency injection! So in our payment project, add a new class called FakePaymentProvider and just have it look somewhat like this:
public class FakePaymentProvider : IPaymentProvider
{
public PaymentResult Execute(string paymentData)
{
if (paymentData == "OK") return PaymentResult.Success;
return PaymentResult.Failure;
}
}
Now the test itself isn’t that hard, we’ve already covered the hardest part and that was doing the actual refactoring. So, this is what my test ended up looking like:
using InversionOfControl.Payment;
using Microsoft.VisualStudio.TestTools.UnitTesting;
[TestClass
]
public class PaymentTests
{
private IPaymentProvider paymentProvider
;
[TestInitialize
]
public void Initialize
()
{
paymentProvider
= new FakePaymentProvider
();
}
[TestMethod
]
public void OrderFailsWithEmptyInformation
()
{
var result
= paymentProvider
.Execute(null);
Assert
.AreEqual(result, PaymentResult
.Failure);
}
[TestMethod
]
public void OrderSucceedsWithOKInformation
()
{
var result
= paymentProvider
.Execute("OK");
Assert
.AreEqual(result, PaymentResult
.Success);
}
} I’m initializing my test by creating a fake payment provider and then I am testing if it fails and succeeds as I expect it to, we’ve got a nice way to test our code! This brings us to the next problem, where Dependency Injection and Inversion of Control meet each other, what if I want to test the flow of my application, without actually changing the concrete instantiations everywhere to FakePaymentProvider?
This is where we’re going to bring in a library to help us along the way, but before we do that, let’s just talk a little bit about what is going to happen.
So we’ve got a system that is now refactored so that the important methods that we want to make testable no longer use the concrete types as parameters but rather interfaces that we can implement to create our fake repositories or providers of some sort. The next thing we want to remove completely is the way that we create an instance of our concrete type before we invoke the payment provider.
To do this, we’re going to use a library that let’s us define what kind of implementation to use in runtime. To do this, I’m going to take some help of NuGet to install a library called Ninject. Ninject is an open source dependency injector for .NET and it’s Very good!
Fire up NuGet and let’s start installing those packages!
All you need to write is the following:
PM> Install-Package Ninject
Be sure that you’ve got “InversionOfControl.Demo” selected as “Default project” and you should see something like this:
There are a lot of different type of dependency injectors out there and they act a little bit different. Ninject works like this: you tell ninject what types you want bound to what types or interfaces and then you request these types. There are other dependency injectors that will just replace all interfaces with the concrete type of your choice, but I like Ninject because it gives us an extra type of abstractness and there’s not that much magic to it.
Basically we need to know two things in order to get started with Ninject ( There’s a great Wiki if you want to know more ) first of all, you use something called “Modules” to easily define different types of bindings. For instance, we’re going to create a module that is called PaymentProviderModule. The second thing is that you use something called a kernel to retrieve the concrete types and you tell the kernel which module it should use.
Let’s start off by creating the module:
using Ninject.Modules;
using InversionOfControl.Payment;
public class PaymentProviderModule : NinjectModule
{
public override void Load()
{
Bind<IPaymentProvider>().To<FakePaymentProvider>();
}
}
All we’re saying here is that each time we ask for an IPaymentProvider we’re going to get a Fake payment provider. Now let’s take a look at how this changes the rest of the code! Let’s head over to the order button event handler. The only thing that actually changes now is how we retrieve a concrete type of IPaymentProvider and this is how we do that with Ninject:
private void ProcessOrderClick
(object sender, EventArgs e
)
{
var kernel
= new StandardKernel
(new PaymentProviderModule
());
ProcessPayment
(orderInformation
.Text, kernel
.Get<IPaymentProvider
>());
} Notice this part in particular kernel.Get<IPaymentProvider>(), we’re actually requesting the interface and not a concrete type! Let’s run the application and see what happens, if we enter anything else than “OK”, we should see a message box that says “Failure”:
And it does!
We’ve successfully made our application less dependent on the concrete type and we’ve introduced testability which we had no way of doing before! The example code for the payment provider is as stated before a bit thin, but in a real world scenario the fake payment provider might not be much bigger than the one we’ve got here, but the real concrete type might.
Now let’s take a look at that definition of Inversion of Control again; it basically means that our application should be able to execute anything against any payment provider without ever having to know about its implementation! We’ve only scratched the surface on how this helps out with testability, there are great frameworks that will help us even more without having to actually create a new concrete type for testing, which in this case was our fake payment provider.
As you might see this is very powerful and gives us a great way to make our applications more testable which will make them more reliable. You can look at the code at the github repository. You can also download the code here.
I hope you found this interesting, if you have any thoughts please leave a comment below!
Vote on HN
Lately a lot of my time has been spent on playing around with Roslyn, if you have no idea what Roslyn is I suggest that you go and read my previous posts on it. One of the things that I challenged myself into doing was creating some soft of service that could execute a code snippet like the interactive window and give me the result back to me. First off I just want to say that I completely Love the C# Interactive Window, I’ve got two posts dedicated to it already!
With that said, let’s step on the gas a bit, a while back there was a blog post about how to replicate the c# interactive window outside visual studio, hence creating a REPL that didn’t require you to run visual studio. This is pretty awesome if you ask me. However the code that you write into the REPL is assumed to be trusted, it doesn’t run in a completely different security context which makes it dangerous if you want to expose it to others.
I’ve been hooked on IRC for many, many years so it came quite naturally to me that I wanted to create an IRC client (bot) that I could send commands to and have the result printed back to me. For those that don’t know what IRC is, it’s short for “Internet Relay Chat”. Basically you can join rooms and have discussions and you can have private conversations and so on. I will only focus on the Roslyn parts here.
So what I wanted to achieve was the following:
- Create an IRC robot that when spoken to, evaluates the message as C# code and prints the result
- The code needs to be run in a secure sandbox
The first one was pretty easy to solve, since I already had code for an IRC client I just needed to do the roslyn integration. The basic idea here is that you take a code snippet, you tell the roslyn script engine to compile this submission into a memory stream and then you execute that in a separate assembly.
Let’s take a look at a diagram of this:
All the green boxes indicate that we are in a secure sandbox and we load and run the code in a low trust AppDomain. Before we get ahead of ourselves, let’s look at how I tried solving the actual code execution before trying to make it secure.
This is a pretty common work pattern, you make something work, you make it fail, you make it work again and then you make it better. Let’s start look at some code!
So the first thing that we need to execute a script is the ScriptEngine and then you will need a Session to keep track on everything. This is pretty simple, let’s say that we want to execute the following code:
Running this in the C# Interactive Window would just print “True”, let’s try to get the same result here like this:
var engine
= new ScriptEngine
();
var session
= Session
.Create();
engine
.Execute("var x = 10; x == 10", session
)If we print the result of this execution it will indeed say “True”. Let us just step away from the keyboard and mouse for a moment, take a deep breath and just think about how amazing this is, this means that we can actually let people write scripts for our applications that! For all you gamers out there, think of LUA and how many plugins there are for world of warcraft. Anyways, back to the code execution.
The biggest problem with this is that it runs in the same assembly as we are and we don’t want to load a sandbox and allow it to use roslyn directly, because roslyn itself needs full trust for the compilation. Keep in mind, we’re still playing with the CTP, much can change when the final release is out there.
Now this means that we can’t use Execute because we want it to be a bit more secure than this, we actually need it to run in another AppDomain. So I converted the above and used the method CompileSubmission<T> instead, this allowed me to compile the code snippet into a memory stream! With some changes of the code, I ended up with something like this:
using (var memoryStream
= new MemoryStream
())
{
engine
.CompileSubmission<object>("var x = 10; x == 10", session
).Compilation.Emit(memoryStream
);
var assembly
= memoryStream
.ToArray();
} To load this into a new AppDomain, you simply do myAppDomain.Load(assembly) however, we are still not quite there yet, we need to have a look at what is generated from the compilation! So instead of using a memory stream I used a file stream and saved the assembly to disk and then inspected it with Reflector 7, this is what ended up in the assembly:
using Microsoft.CSharp.RuntimeHelpers;
using Roslyn.Scripting;
using System;
public sealed class Submission
#0
{
public int x
;
public Submission
#0(Session session, ref object submissionResult)
{
SessionHelpers
.SetSubmission(session,
0,
this);
this.x = 10;
submissionResult
= (this.x == 10);
}
public static object <Factory
>(Session session
)
{
object result
;
new Submission
#0(session, ref result);
return result
;
}
} This all look very good, until you really think about what happens when you do Cross-AppDomain things, everything that is sent to another app domain needs to be serializable and Session is not. By this time I got some help from some never nice guys over at Microsoft which really helped me along the way.
Again, keep in mind that this is only CTP, I hope that Roslyn will contain something that will make hosted execution much easier in the future.
So this means that we can’t use ScriptEngine at all, we need to take a look at something else, we actually have to do a “real” compilation using a compiler object from Compilation.Create(). This will also let us emit our output to a memory stream. However we are presented with some more problems, the code that is executed will be inside an internal class so we need to send another class that actually instantiates it and gives us the value.
Sounds confusing? It might get a bit clearer in a little bit.
The “other” class that I compile with the script is this one:
public class EntryPoint
{
public static object Result { get; set; }
public static void Main()
{
Result = Script.Eval();
}
}
The name Script is actually the name of the class that will hold our “script”, you can change that name if you’d like. As you can se all we are doing here is setting our public static variable called Result to whatever Eval() will return.
This brings us to the interesting part. I had to make some compromises, instead of just being able to write “1 == 2″ I now have to write “return 1 == 2;” it’s not really a hassle once you get use to it. So what does Eval() look like? It’s actually a method that I had to define, it will be inside the Script class and it will look like this:
var script = "public static object Eval() {" + code + "}";
As you can see I am actually concatenating some code variable into the method, which means that it will look like this with the above example:
public static object Eval()
{
return 1 == 2;
}
Which means that so far I had something like this:
public object Execute(string code)
{
const string entryPoint =
"using System.Reflection; public class EntryPoint { public static object Result {get;set;} public static void Main() { Result = Script.Eval(); } }";
var script = "public static object Eval() {" + code + "}";
}
Before I actually compile this code I want to create my sandbox, the reason for me creating the sandbox before I compile is because I want to load some assemblies into the sandbox so I can use the file locations of the assemblies when I am compiling. To create the sandbox I simple used this method:
private static AppDomain CreateSandbox
()
{
var e
= new Evidence
();
e
.AddHostEvidence(new Zone
(SecurityZone
.Internet));
var ps
= SecurityManager
.GetStandardSandbox(e
);
var security
= new SecurityPermission
(SecurityPermissionFlag
.Execution);
ps
.AddPermission(security
);
var setup
= new AppDomainSetup
{ ApplicationBase
= Path
.GetDirectoryName(Assembly
.GetExecutingAssembly().Location) };
return AppDomain
.CreateDomain("Sandbox",
null, setup, ps
);
} This will give us a new AppDomain that we can use that has a trust level of Internet, which will not allow for any type of I/O and many other things.
So my next step is to create the sandbox and reference System and System.Core inside it.
var sandbox = CreateSandbox();
var core = sandbox.Load("System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089");
var system = sandbox.Load("System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089");
Next up is to create the actual compilation object, this is how that works:
- Select what type of assembly it is
- Set the namespaces that you want to use
- Include all the syntax trees that you want to compile into the assembly
- Set which references to include in the compilation
The last one is why we loaded the Assemblies before hand, the references are referenced using a MetadataReference and unfortunately there is not one that successfully takes a fully qualified name (that works.). So this is a work around until that issue is fixed. So this is how it ends up:
var compilation
= Compilation
.Create("foo",
new CompilationOptions
( assemblyKind
: AssemblyKind
.ConsoleApplication,
usings
: ReadOnlyArray
<string>.CreateFrom(
new[] {
"System",
"System.IO",
"System.Net",
"System.Linq",
"System.Text",
"System.Text.RegularExpressions",
"System.Collections.Generic" })),
new[]
{
SyntaxTree
.ParseCompilationUnit(entryPoint
),
SyntaxTree
.ParseCompilationUnit(script, options
: new ParseOptions
(kind
: SourceCodeKind
.Interactive))
},
new MetadataReference
[] {
new AssemblyFileReference
(typeof(object).Assembly.Location),
new AssemblyFileReference
(core
.Location),
new AssemblyFileReference
(system.Location)
});By now we should be ready to actually compile! This looks almost exactly like what we did before:
byte[] compiledAssembly
;
using (var output
= new MemoryStream
())
{
var emitResult
= compilation
.Emit(output
);
if (!emitResult
.Success)
{
}
compiledAssembly
= output
.ToArray();
} As you can see here, we’ve actually got an emit result that we can use to see if the compilation failed or not, which would be appropriate to tell the person sending code for execution. You can get the errors like this:
emitResult.Diagnostics.Select(x => x.Info.GetMessage());
Now the next step is to actually load this assembly into our sandbox, but to do that, we need to do one more thing. We need to create a class that is a MarshalByRefObject, we need this proxy in order to load the compiled assembly into the sandbox.
It simple looks like this:
public sealed class ByteCodeLoader
: MarshalByRefObject
{
public ByteCodeLoader
()
{
}
public object Run
(byte[] compiledAssembly
)
{
var assembly
= Assembly
.Load(compiledAssembly
);
assembly
.EntryPoint.Invoke(null,
new object[] { });
var result
= assembly
.GetType("EntryPoint").GetProperty("Result").GetValue(null,
null);
return result
;
}
} As you can see there is already code in the Run-method to actually get the Property-value of Result. If you remember the class EntryPoint looked, you know that we first need to create an instance of it and then get the property in order for it to actually be set. Let’s keep going, we’ve still got a couple of more things to do before this is all set.
What we can do now is actually create an instance of the ByteCodeLoader inside the sandbox AppDomain and then call Run(), you can see this as some sort of proxy:
var loader
=
(ByteCodeLoader
)Activator
.CreateInstance(sandbox,
typeof(ByteCodeLoader
).Assembly.FullName,
typeof(ByteCodeLoader
).FullName)
.Unwrap();Now we are actually all set! We can run this code inside our sandbox app domain! What happens if someone would execute this code:
This would both compile and run fine. To avoid this, let’s run the code inside a thread and abort it after a fair amount of time:
var scriptThread
= new Thread
(() =>
{
try
{
result
= loader
.Run(compiledAssembly
);
}
catch (Exception ex
)
{
result
= ex
.Message;
}
});
scriptThread
.Start();
if (!scriptThread
.Join(6000))
{
scriptThread
.Abort();
AppDomain
.Unload(sandbox
);
}After we’re done, we just Unload the AppDomain and all it’s referenced assemblies to free up memory.
By this time, I thought everything was running smoothly, until someone tried this:
Action f = null; f = () => { f(); f(); }; f(); return 1;
This will actually cause a StackOverflowException and in .NET 2.0 and above, you cannot recover from that. This felt of course as being back on square one, the things is that if you have a child AppDomain and it throws a StackOverflowException it will travel back to the parent and be thrown there as well. The only solution is to run this inside another process.
So I figured that the best way to do this is to run this as a Windows Service and communicate with the system over a named pipe! The best part is that the code execution can still be intact, we don’t need to change that! We’re going to use WCF to communicate with our named pipe and the contract will look like this:
using System.ServiceModel;
[ServiceContract(Namespace = "http://example.com/RoslynCodeExecution")]
interface ICommandService
{
[OperationContract]
string Execute(string code);
}
Pretty simple, but there’s not really much more to the contract, we just want to execute code and get a result back to us. So let’s have a look at the actual implementation, what we want to do here is that we want to run our code execution and get an unformatted object back then we want to return a formatted result back over the pipe, so this is how I did the implementation of the CommandServer:
[ServiceBehavior
(InstanceContextMode
= InstanceContextMode
.Single)]
internal class CommandService
: ICommandService
{
public string Execute
(string code
)
{
var engine
= new CodeExecuter
();
try
{
var unformatted
= engine
.Execute(code
);
var formatter
= new ObjectFormatter
(maxLineLength
: 350);
return formatter
.FormatObject(unformatted
);
}
catch (Exception ex
)
{
}
return string.Empty;
}
} Using the object formatter means that if it returns an array of bytes, the actual string we will get back will look like this:
byte[32] { 54, 68, 32, 54, 53, 32, 52, 48, 32, 54, 56, 32, 54, 70, 32, 54, 68, 32, 54, 53, 32, 50, 69, 32, 54, 51, 32, 54, 70, 32, 54, 68 }
Now all we need to do is start the named pipe and listen to it like this:
static class CommandServer
{
private static readonly Uri ServiceUri
= new Uri
("net.pipe://localhost/Pipe");
private const string PipeName
= "RossieEngineService";
private static readonly CommandService Service
= new CommandService
();
private static ServiceHost _host
;
public static void Start
()
{
_host
= new ServiceHost
(Service, ServiceUri
);
_host
.AddServiceEndpoint(typeof(ICommandService
),
new NetNamedPipeBinding
(), PipeName
);
_host
.Open();
}
public static void Stop
()
{
if ((_host
== null) || (_host
.State == CommunicationState
.Closed)) return;
_host
.Close();
_host
= null;
}
} This is just standard code to get the named pipe running and all the actual service will do now is this:
var thread
= new Thread
(CommandServer
.Start);
thread
.Start();Play with the thought that the service is running nicely now, it might have for days and then someone decides to run code that results in a StackOverflowException, what will happen? By the looks of it, it will still not recover from it. Let’s take a look at a changed diagram to figure out how to solve this, because what will happen is that the Windows Service will just be marked as Not Running
So this means that we actually don’t have to change anything on either the service or the code executor! We just need to think about how we use this from the client side. The first thing we need to do is to copy ICommandService into the client project.
We will also need this in the client to be able to use the named pipe:
private static readonly Uri ServiceUri
= new Uri
("net.pipe://localhost/Pipe");
private const string PipeName
= "RossieEngineService";
private static readonly EndpointAddress ServiceAddress
= new EndpointAddress
(string.Format(CultureInfo
.InvariantCulture,
"{0}/{1}", ServiceUri
.OriginalString, PipeName
));
private static ICommandService _serviceProxy
; Then we add a method that will create a new ChannelFactory<T> each time we invoke it, this way we can make sure that the channel is always open:
private static void StartCodeService
()
{
var service
= new ServiceController
("Rossie Engine Service");
if (service
.Status != ServiceControllerStatus
.Running)
{
service
.Start();
service
.WaitForStatus(ServiceControllerStatus
.Running);
}
_serviceProxy
= ChannelFactory
<ICommandService
>.CreateChannel(new NetNamedPipeBinding
(), ServiceAddress
);
} As you can see it also checks if the service is running, if it’s not, we start it and wait for it to start. This will however present us with a new problem, in order to start a service the client application needs to run with administrator privileges. Now all that is left for us to do is to start the code service and execute code!
So this is the final piece of code that will look like this:
StartCodeService();
var serviceResult = _serviceProxy.Execute(code);
Where code is some variable we’ve filled up with code to run. I get that this has been a lot to take in, so the entire project is hosted on GitHub, it’s open source, go and have fun with it!
I’ll leave you with a final demo of the demo application that you can download from the github project:
I hope you found this interesting, if you have any thoughts please leave a comment below!
Vote on HN
Filip Ekberg is a Senior Software Engineer working in the country with all the polar bears, author of a self-published C# programming book and overall in love with programming.
