sâmbătă, 15 august 2009

IoC in .NET part 1: Autofac

This is an interesting IoC project that I used in a couple of occasions, nothing big, but I sure enjoyed it immensely.

Autofac is wrist friendly so to speak and it tries to solve your configuration problems in a simple and concise manner.

Without further ado go at http://code.google.com/p/autofac/ to get the latest version.

Next I’ll try to create a simple example that I hope we’ll use for the most part of this series.

In learning the inner workings of IoC containers we’ll develop a console application that provides some simple autocomplete for it’s features.

The features of our application are:

  • Autocomplete for internal commands
  • Commands
    • Alert – displays a message box
    • NewLine – goes to the next line
    • Calculator – with support for add

All of this features will be organized under the Components folder as functions and services.

In general you will want the concrete classes to be linked to an interface, and is by default the way I like to handle it.

A lot of voices in the community are against the use of xml files for configuration, and to that regard Autofac offers the option of using a fluent interface for configuring the builder. Although good for contracts that you are not likely to change without recompiling the application, when you need to have functionality similar to that of a plug-in you will prefer to use an IoC capable of reading xml configuration. Obviously Autofac has support for xml files as well.

Note xml configuration support is very limited in Autofac, so I’ll only show the bootstraping for this file

As I said earlier an IoC is just a form of factory, the only real difference is that this is a factory with nice configuration capabilities.

In more complex applications I recommend you use modules for configuring but for this example is sufficient to have everything configured in only one place.

As a preference I always configure the IoC I’m using in a class called Bootstrap in my highest level module ( commonly identified as the assembly containing the Main function, or if in a web app the assembly that contains the Global.asax).

The code for the Bootstrap.cs looks like this:

public class Bootstrap
{
public static IContainer Components(){
var builder = new ContainerBuilder();

builder.Register<ConsoleClearScreen>().As<IClearScreen>().SingletonScoped();
builder.Register<ConsoleWriteString>().As<IWriteString>().SingletonScoped();

builder.Register<AlarmFunctionState>().As<IFunctionState>().Named( "AlarmFunctionState" );
builder.Register<NewLineFunctionState>().As<IFunctionState>().Named( "NewLineTransition" );
builder.Register<CalculatorFunctionState>().As<IFunctionState>().Named( "CalculatorTransition" );


builder.Register<IConsoleInputService>(
c => new ConsoleInputServiceImpl(
new IFunctionState[]{
c.Resolve<IFunctionState>("AlarmFunctionState"),
c.Resolve<IFunctionState>("NewLineTransition"),
c.Resolve<IFunctionState>("CalculatorTransition")
} ) );

return builder.Build();
}
}


Autofac uses the ContainerBuilder class to register services and it offers a simple method of directly creating those services through the use of lambda expressions.



For the actual implementation of the app you can download the source code here.

joi, 13 august 2009

Checkout the Windows 7 API Code Pack for .NET

The individual features supported in this version (v1.0) of the library are:

  • Windows 7 Taskbar Jump Lists, Icon Overlay, Progress Bar, Tabbed Thumbnails, and Thumbnail Toolbars.
  • Windows 7 Libraries, Known Folders, non-file system containers.
  • Windows Shell Search API support, a hierarchy of Shell Namespace entities, and Drag and Drop functionality for Shell Objects.
  • Explorer Browser Control.
  • Shell property system.
  • Windows Vista and Windows 7 Common File Dialogs, including custom controls.
  • Windows Vista and Windows 7 Task Dialogs.
  • Direct3D 11.0, Direct3D 10.1/10.0, DXGI 1.0/1.1, Direct2D 1.0, DirectWrite, Windows Imaging Component (WIC) APIs. (DirectWrite and WIC have partial support)
  • Sensor Platform APIs
  • Extended Linguistic Services APIs
  • Power Management APIs
  • Application Restart and Recovery APIs
  • Network List Manager APIs
  • Command Link control and System defined Shell icons.

 

More details at : http://code.msdn.microsoft.com/WindowsAPICodePack and http://www.infoq.com/news/2009/08/WIndows-7-DotNET

Javascript gotcha


Usually the style you organize code is just that A MATTER OF STYLE, in javascript however it’s not.




If by any chance you end up writing the following code:



 



var display = function() {
this.x = 10;
return
{
alert: function(message) {
window.alert(message);
}
}
}


you might be in for a surprise but it won’t return anything because by default the javascript interpreter inserts ; after every line that doesn’t already contain it or }.



Instead you should write:



var display = function() {
this.x = 10;
return {
alert: function(message) {
window.alert(message);
}
}
}


More interesting notes you can find in the next video:






Hope you enjoyed this I sure did :D.


What is an IoC ?

Disclaimer: This is a series of posts in which we’ll go through the IoC’s that are used in today’s applications

The most simple answer I can give you is this:

It’s an abstraction over Factory Method.

It helps, in my opinion to think of this as a factory method, because then you know what to expect of it, since it constructs/resolves a specific implementation based on the configuration you provide it.

In a factory method you write, aka “hard code”, the implementation you will be using. In an IoC container you basically do the same except it’s easier to change, if you write it in the xml file since using it in code leaves you with what you started and never got to changing it.

However, an IoC has an additional plus over the hand coded factory, that is “It is able to construct objects  based on the configuration you supplied”.

Does it help ?

Oh yes it helps. There’s a principle in software that states “High level modules should not depend on low level modules, both should depend on abstractions”. And guess what the principle I just stated is the Dependecy Injection Principle, it is an important point to note since IoC containers are often referred  to as Dependency Injectors. So you will probably find the IoC/DI whenever reading about an IoC.

With the help of an IoC you can declare dependencies of you object using abstractions, usually in the form of interfaces and/or base classes.

In the next part will explore a couple of IoC’s that the .NET has to offer as well as from the outside of the .NET ecosistem.

I hope that by the end of this series we can form a summary of benefits and deduct some ground rules for choosing a certain IoC, or deciding if we need it.