Documentation for NanoContainer.NET

Been working on clearing up some of the issues with NanoContainer.NET and believe to have gotten to a point where hopefully we can consider going forward with a release. First thing that need to be done is documentation, so I have started to create documentation specific to the .NET implementation of NanoContainer. Take a look here.

Custom Attributes for NanoContainer.NET

I recently rolled onto the Beach after working on the same project for the past 7+ months. The project successfully utilize PicoContainer.NET for configuring both the client and server.

A colleague of mine, Jay Fields, and I have been discussing the use of .NET Attributes with pico/nano. I have for a while felt that the .NET implementation of pico and nano have really just been straight ports of the Java code while not really taking advantage of the features C# offers. One particular useful addition are Attributes.

So the past few days we have worked on a spike to take advantage of Attributes in the NanoContainer.NET. Utilizing Attributes in the code will allow us to define how an object is added to the container and will free us from having to create a separate script for loading the container. Here is an overview of the work we have done:

Attribute:

RegisterWithContainerAttribute - This is a class level attribute used by concrete classes that need to be registered with the container. The properties of this class are:

• object key: which represents the key the component should be registered against
• ComponentAdapterType componentAdapterType: An enum that defines the type of component adapter (choices consist of Caching, NonCaching and Custom). Caching is the default.
• DependencyInjectionType dependencyInjectionType: An enum that defines the DI construct to follow (Constructor or Setter are the choices) as expected Constructor is the default type.
• Type componentAdapter: represents the concrete Type to use as the component adapter. This allows a concrete class to define a custom component adapter to use for itself.

Examples of use:

// constructor based with caching...
[RegisterWithContainer]
public class Foo : IFoo
{
 private IBar bar;
 public Foo(IBar bar)
 {
    this.bar = bar;
 }
}

// setter based with caching
[RegisterWithContainer(DependencyInjection=DependencyInjectionType.Setter)]
public class Foo : IFoo
{
 private IBar bar;

 public IBar Bar
 {
    set {this.bar = value; }
 }
}

// constructor based with non-caching...
[RegisterWithContainer(ComponentAdapterType.NonCaching)]
public class Foo : IFoo
{
 private IBar bar;
 public Foo(IBar bar)
 {
    this.bar = bar;
 }
}

// setter based with non-caching...
[RegisterWithContainer(ComponentAdapterType.NonCaching,
     DependencyInjection=DependencyInjectionType.Setter)]
public class Foo : IFoo
{
 private IBar bar;

 public IBar Bar
 {
    set {this.bar = value; }
 }
}

// utilize a custom component adapter (caching and injection type are ignored for custom)
[RegisterWithContainer(ComponentAdapterType.Custom,
      ComponentAdapter=typeof(CustomComponentAdapter))]
public class Foo : IFoo
{
 private IBar bar;
 public Foo(IBar bar)
 {
    this.bar = bar;
 }
}

// example of the custom component adapter...
public class CustomComponentAdapter: CachingComponentAdapter
{
 public CustomComponentAdapter(Type type) 
    : base(new ConstructorInjectionComponentAdapter(type))
 {
 }
}

Now the CustomComponentAdapter doesn't really serve a purpose in this example, but I think it gets the point across. I think this addition to NanoContainer.NET is extremely useful and takes advantage of the language features. I think it also opens up the idea of utilizing similar functionality for Java 5.0 Annotations. Consistency between the two would be great.

Dynamic Proxy missing from C#

There are many things about the C# language I really like and think Java would benefit from having. On the flip side of that several Java features are also sorely missed in C#. One in particular is dynamic proxy. The java implementation of dynamic proxy is java.lang.reflect.Proxy which is an extremely powerful feature. For those unfamiliar with dynamic proxy take a look at the JavaDoc to gain a deeper understanding of it.

For those who aren't interested in reading the JavaDoc here is a quick overview. Basically a dynamic proxy allows you to generate an instance of an Interface(s) at runtime without the need of a real implementation. So for example we have an Interface Foo

public interface Foo {
    String hello();
}

We can create an instance of Foo without having to have a class defined which actually implements Foo. In Java we can do this like so:

ClassLoader classLoader = Foo.class.getClassLoader();
Class[] interfaces = new Class[] { Foo.class }; // list of interfaces to support
InvocationHandler invocationHandler = ... // custom impl of InvocationHandler
Foo instance = (Foo) Proxy.newProxyInstance(classLoader, interfaces, invocationHandler);

Now the actual power of this is handled in the implementation of the InvocationHandler. Here is a simple implementation of the InvocationHandler which traps method calls to the method hello().

public class FooInvocationHandler implements InvocationHandler {
    public Object invoke(Object proxy, Method method, Object[] args) {
        if(method.getName().equals("hello")) {
            System.out.println("The hello method was called!");
        }
        return "world";
    }
}

While this is a very trivial example it does show how easy it is to create a proxy and how potentially powerful they are. Adding AOP type of functionality to method calls is simple to do, such as Security checks and the overused logging example.

Well back to my point. When working on the .NET port of PicoContainer I needed the ability to utilize a dynamic proxy for the ImplementationHidingComponentAdapter. This ComponentAdapter hides the implementation from the container. I figured I would easily be able to convert this logic to the C# port. To my surprise C# does not provide an out of the box simple implementation of dynamic proxy. They do provide the Emit API which will allow you to create your own proxy behavior for it. But creating a sufficient implementation of dynamic proxy from the Emit API is not a trivial task. Luckily the open source community has created an implementation of dynamic proxy for .NET called DynamicProxy.

Best to follow the documentation on the website itself or the related article on The Code Project. It's a good implementation and thoroughly tested. PicoContainer.NET utilizes it, as well as NHibernate. One caveat however is that at the moment it does not work with Mono, hopefully that will be fixed.

Mono error:

** ERROR **: file class.c: line 2820 (mono_ldtoken): should not be reached

It would be great if Microsoft would add dynamic proxy support to the language but until then DynamicProxy seems like an nice tool.

JetBrains MPS: Meta Programming System

The folks over at JetBrains, makers of the excellent IntelliJ IDE, have released their latest project MPS or Meta Programming System. MPS appears to be a Language Workbench. The concept seems extremely interesting, and could potentially be a huge change with how systems are developed.

MPS can be downloaded through the EAP program JetBrains offers. MPS appears to have a dependency on the latest IntelliJ IDEA code named Irida, which too is available through JetBrains' EAP. The MPS is itself a plug-in for Irida IDE.

Languages , languages and more languages.

Earlier this year I started working with .NET, C# specifically. Since then I have also started to jump on the Ruby bandwagon. Most recently I've gone back in time and started re-learning C++. It's enjoyable spending time and getting into each language. I think it is valuable to have an understanding of what else is out there. Without a doubt I can see how expanding my knowledge with these languages will benefit me in general. I find that opening my mind to different concepts helps me with me think of things like: "How can I do something similar to this in Java?", or "What is the equivalent syntax for this in C#."

Next steps Ruby on Rails... or maybe I'll have to break out my old SmallTalk books.

Project Structure for .NET applications

Over the last few months I have been working more and more with .NET (C# specifically). After working almost exclusively on Java projects for the last several years I have a bias for how a project should be laid out. However, I quickly realized that a Java projects structure does not translate easily to .NET. This seems specifically related to the nuances of Visual Studios.

I initially started investigating the different layouts for several popular .NET open source projects. Each project I looked at varied greatly in how it was laid out.
I was surprised to see that no common approach existed for .NET projects.

The following is a quick overview of how I have structured projects. I'll use PicoContainer as an example:

Java Project Structure

-- picocontainer
   -- lib
   -- src
      -- java
         -- org
            -- picocontainer
               -- defaults ...
      -- test
         -- org
            -- picocontainer
               -- defaults ...

.NET Project Structure

-- picocontainer
   -- lib
   -- src
      -- PicoContainer
         -- Defaults ...
      -- PicoContainer.Tests
         -- Defaults ...

The main difference is how package naming in Java does not translate easily to namespaces in .NET. The folders PicoContainer and PicoContainer.Tests are each separate Assemblies. PicoContainer.Tests of course contains a reference to PicoContainer. The differences are of course minor but from what I have seen there does not yet seem to be a standard project structure for .NET.

The advantage of the .NET layout is it works well with Visual Studios and does not require any tweaking of the project properties. Hacking the properties just makes things confusing and less intuitive.