My feelings on magic

(Feel free to skip this section if you couldn’t care less about my thoughts on automagic)

I am not the biggest fan of automagical behavior. For that reason, up until now, Glue has not automatically created new objects when you map. You have to instantiate the object to map to (and all nested objects within that object). The reason for this is that I want the developer to explicitly decide when it comes to how objects are to be created. Personally I like to be in control, so that problems do not arise at inconvenient times (like at runtime in a production environment).

In addition, I come from the OO school. I believe that objects should be, yes, objects, and not just data containers (a typical data container is a class containing only properties, and little or no logic). I believe objects should be relevant, individual, and contain logic. This often means that constructing them is not something you let a framework do (unless it is a framework specialized for that kind of job). Because constructing them often means making decisions, like what dependencies these objects should have.

The “General purpose” mapping framework

One of the driving forces for creating Glue was to create a general purpose mapping framework. Meaning it should support different scenarios, not just the ones I liked the most. In addition, using Glue extensively myself, I have found that there are (quite a lot of) times when having Glue create objects for me are both convenient, and low risk.

Automagical and Strict mode

So, with version 0.9 of Glue, I introduce the “Automagical” mode where Glue tries to instantiate objects whenever necessary. In addition, the existing behavior (making you create all the objects) is now named “Strict” mode. Choosing between the modes is simply done by choosing the right overload of the Mapper.Map-method. Intellisense will guide you.

Examples can be found here

(What is Glue?)

Download Glue 0.9 binaries here

- Tore Vestues

Also no doubt, we have not had such excellent package management system in the .Net-sphere. So why not just make RubyGems work for .Net as well? That’s exactly what Dru Sellers have done with Nu.

This is a great idea, so I decided right away to make a Gem out of Glue.

To use it, start your favorite windows shell and type:

gem install gluemapping

Then go to your project directory (if you’re not already there) and type

nu install gluemapping

That’s it! The newest Glue-assemblies will be put in the lib-folder in your project directory.

Requirements:

1. You will need to install ruby. Download the latest rubyinstaller, and install it.
2. Install Nu:

gem update --system
gem install nu


You can find more information on Nu here.

The Gem is hosted at RubyGems, you can find information about it here.

- Tore Vestues

There are many ways to use reflection, and the performance on them vary a lot. What we did was to try out every method and timing them to measure performance. These are the methods we tested: Normal property access, normal reflection, compiling and invoking a compiled expression, using Emit to create, compile and run the statement.

Normal property access

To compare the other methods, we measured the performance on accessing a property the normal way:

1

Run("Normal property access", () => { var city = address.City; });

It was no surprise that this was the fastest method.

Normal reflection (250 times slower than normal property access)

1
2

var cityPropertyInfo = typeof (Address).GetProperty("City");
Run("With reflection", () => cityPropertyInfo.GetValue(address, new object[0]));

This is what most of us think about when talking about reflection. This is also the by far most common method of reflection used in Glue. Although about 250 times slower than normal property access, this method has very strong sides compared to the other methods.

Invoking compiled expressions (twice as slow as normal property access)

1
2
3

Expression<Func<Address, string>> expression = x => x.City;
var func = expression.Compile();
Run("Invoke compiled expression", () => func.Invoke(address));

Using compiled expressions is another way of dynamically invoking members on objects. Due to the syntax exposed in the api in Glue, most mapping specifications enter Glue as (uncompiled) expressions. The fact that it is only about twice as slow than normal property access, is very promising. But there is a catch, a big one. In order to invoke this way, the expression must be compiled. It is not compiled when it enters Glue, so we have to include the time it takes to compile the expression as well.

Compile Expression and invoke it (51700 times slower than normal property access)

1
2
3
4
5

RunLong("Compile Expression and invoke", () =>
             {
                 var compiledFunction = expression.Compile();
                 compiledFunction.Invoke(address);
             });

Yes, if you have to compile an expression before invoking it, it takes about 200 times longer to do the operation than with normal reflection. Leaving this a unattractive method to use with Glue.

Using Emit, invoking a compiled expression (4 times slower than normal property access)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

private Func<Address, string> GetEmitDelegate()
{
    var dm = new DynamicMethod("TestMethod", typeof(String), new [] {typeof(Address) }, typeof(Address).Module);
 
    MethodInfo getCity = typeof(Address).GetProperty("City").GetGetMethod();
 
    ILGenerator il = dm.GetILGenerator();
    il.Emit(OpCodes.Ldarg_0);
    il.EmitCall(OpCodes.Call, getCity, null);
    il.Emit(OpCodes.Ret);
 
    return (Func<Address, String>)dm.CreateDelegate(typeof(Func<Address, String>));
}
 
var emitDelegate = GetEmitDelegate();
Run("Emit: run compiled statement", ()=>emitDelegate(address));

My guess is that using Emit is not something you will be doing a lot. But, we had to try. Again, executing a compiled expression was fast. But as with expressions, the problem comes when you have to compile before running.

Using Emit, create statement, compile it and run (39000 times slower than normal property access)

1

RunLong("Emit: Create statement, compile, run",()=>Emit(address));

As we can see, this is also horribly slow.

Conclusion

Unless you can create an expression/emit statement and compile it and then run the compiled version more than 200 times, in the app’s lifetime, using normal reflection is by far the preferred way to go when you have to dynamically invoke members on objects.

- Tore Vestues

Thanks to Åsmund Eldhuset.

Here’s the source

I’m actively developing it. I’m also actively using it. In this post I’ll share my experience as a user of Glue, and how easy it is to set up the mappings using TDD.

The example

We want to create a mapping between DomainPerson and GuiPerson, listed here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class DomainPerson
{
    public int Id { get; private set; }
    public String Name { get; set; }
    public DomainAddress Address { get; set; }
}
 
public class DomainAddress
{
    public String StreetAddress { get; set; }
    public int ZipCode { get; set; }
    public String City { get; set; }
    public String Country { get; set; }
}
 
public class GuiPerson
{
    public int Id { get { return 0;} set { return;} }
    public String Name { get; set; }
    public String StreetAddress { get; set; }
    public int ZipCode { get; set; }
    public String City { get; set; }
    public String Country { get; set; }
}

Making sure all properties are related

What I test first is that all the properties are related (or actively ignored). This makes it easy to later detect changes in the classes we map between. It also makes it easy for us to see what properties we have to handle.

But first, in traditional TDD style, lets start with writing a failing test. The test should verify that all properties on GuiPerson are either related or actively ignored. The test looks like this:

1
2
3
4
5

[Fact]
public void AsserAllPropertiesRelated()
{
	mapping.GetRelationsVerification().AssertAllPropertiesRelated<GuiPerson>();
}

and, as this will not compile, let’s create the actual mapping:

1

mapping = new Mapping<DomainPerson, GuiPerson>();

It compiles, but as expected, it fails. We have created a mapping, but nothing is related. A nice feature with Glue is that it tries to be as informative as possible when it fails. Look at the exception we receive when running this test:

Not all properties are related (or ignored): Id, Name, StreetAddress, ZipCode, City, Country

It tells us what properties we need to handle. This makes my job easy. I’ll just have to relate (or ignore) all the properties reported in the exception:

1
2
3
4
5
6
7

mapping.Relate(domain=>domain.Id,gui=>gui.Id);
mapping.Relate(domain => domain.Name, gui => gui.Name);
 
var addressMapping = new Mapping<DomainAddress, GuiPerson>();
addressMapping.AutoRelateEqualNames();
 
mapping.Flatten(domain=>domain.Address,addressMapping);

Running the test, I get another Exception:

Glue.GlueException : The relation between ‘Id’ and ‘Id’ has atleast one readonly property, and can not be related TwoWays

Ah, fair enough, it went a bit fast there. I related all properties, but I didn’t check if any where readonly. Luckily, Glue tells us this early. I’ll make this change:

1

mapping.RelateTowardsRight(domain => domain.Id, gui => gui.Id);

And when I run the test again, it goes green. Now all properties are related, and we are protected from future changes.

Make sure the mapping actually works

But will it really work? We can also easily check if the actual values can be set on the target object. You should do this. I always do. So, lets start with another test:

1
2
3
4
5

[Fact]
public void AssertMappingWorks()
{
    mapping.GetMapperVerification().AssertMapsCorrectlyTowards(new GuiPerson());
}

Running this test, we get an Exception:

Glue.GlueException : Failed properties: Id (Failed to set value)

Ah, it detected that Id on GuiPerson is totally unable to set. Ok, lets say that this is supposed to be this way. That means we should not map Id towards GuiPerson. That means that we must remove this:

1

mapping.RelateTowardsRight(domain => domain.Id, gui => gui.Id);

Running the tests again makes AssertMappingWorks gets green, but now AsserAllPropertiesRelated got red again. That is because we have not related Id on GuiPerson. But since we do not want to relate it, we ignore it, to signal that we actively have made that choice. We do it like this:

1

mapping.IgnoreTowards<GuiPerson>(gui=>gui.Id);

Running the tests, they both are green, and now we know that we have a working mapping, which also are protected from failing on future changes.

Note that this example only tests the mapping and relations towards GuiPerson, in a bidirectional mapping scenario I advice to write the same two tests towards DomainPerson.

This is how I do it, and it works great for me. Hope you liked it. To learn more about Glue, and to download it, go to the Glue homepage at Codeplex

- Tore Vestues

You’ll find examples and code here: http://glue.codeplex.com

Glue is a general purpose, bidirectional automatic mapping for the .Net platform, with strong verification and testing tools.

I’ve seen quite a lot of less than optimal handling of mapping issues in quite a few projects over the years. Again and again mapping seems to be just a task we have to do, and a bit too small for automating. It becomes clearer and clearer to me that mapping is both an important task in many projects, and it is always a repetitive and boring task. In addition far to often subtle annoying bugs tend to sneak into mapping code. This motivated me to create Glue. And this is what I need from a mapping framework:

a) a way to automate mapping, mostly because it is boring, and that makes it error prone,
b) a way to automatically test the mapping, I’ve found that manual written test code for mapping is seldom done in a good way,
c) a way to prevent future changes making my mappings obsolete. When people make changes, they rarely focus on mapping (and honestly they should not either). They should be told when they have to update the mapping.

Now, you could argue that there is already a mapping framework available on the .Net plattform. And when I started this work, I actually started with that framework, thinking I could just make a few extensions to fulfil my needs. I actually spent some time in the source code to try to implement it, but sadly I realized that our needs differed too much. So, I created Glue, and these where the driving forces:

General purpose

Glue is a general purpose mapper. We realize that in the real world there are a lot of different solutions, and not all of them follow “the one true pattern”. In fact, mapping is often used to map to and from subsystems that are far from well designed. Subsystems we try to hide in a layer because we do not want it to leak into the other layers. Thus, we believe a mapper must support quite a few different scenarios. The goal is to promote good coding practices, but not to ignore the fact that there is a lot of legacy code out there that forces us to work a bit differently at times.

Bidirectional

I would say that in many mapping scenarios we need to map in both directions. First we get data from an object in a layer, and map it to an object in the layer above. When that layer is done with manipulating that object, we often want to map it back to down to the layer where it all came from. I have noticed not all mapping frameworks see it this way, and this was one of the reasons why I started working on Glue instead of trying to extend existing frameworks.

Strong verification and testing tools

I want to be absolutely certain that my mapping works. I also want to make sure that it is very hard to break it later. Manually writing tests for mapping is even more tedious than writing manual mapping. Glue automates this. Future changes has a sad reputation of breaking mapping code. Glue helps you detect this. Tools for helping the mapping is very important to me. And more tools will be available in future releases.

Simplicity

Mapping should be simple. Glue tries to simplify both the mapping process, and the verification and testing. You should not have to state the obvious, and Glue support relating properties automatically based on names.

Explicitness

Although Glue enables you to automate much of the mapping process, it also gives you the opportunity to be explicit about the mapping. So if you want to describe every relation in detail, you can. When it comes to understandable code this can be a good thing. Taking difficult to understand implicit mappings, and stating them explicitly can sometimes make things much easier to understand.

Current version and the future

The current version is 0.2.0 Alpha. It is still in Alpha because if we find good ways to improve the API, we do not want to lock ourselves to it just yet, before we get more feedback. I’m guessing the next release will be Beta.

I am currently using Glue on the project I am working on, and in about a month it will reach production. This somewhat guarantees that it will continue to evolve as our needs expand, and that we will find bugs sooner, and they will be fixed sooner.

Looking into the future we have some exciting ideas on tools to help with the mapping, and we are also working hard to make Glue as easy as possible to use, so expect simplifications. In addition we want Glue to serve a broad set of needs, so feedback is highly appreciated and if you explain your special needs, we might just implement it.

You’ll find examples and code here: http://glue.codeplex.com

- Tore Vestues

In my last project we used the ASP.NET MVC framework along with StructureMap, which made us create our own controller factory. I just blogged about it here.

If it was a good design decision or not I am not completely certain anymore, but we added some more framework logic to the controller factory, including checking state on the HttpRequest-object. This, it turned out, was a path to trouble. After a while we had unexpected behavior in our system, sometimes it leaked information between HttpRequests it seemed! But since this only happened during stress testing, it was hard to find the cause.

What we found was that the RequestContext.HttpContext-object was not all the way thread safe. When a request hits our custom controller, and the request goes to sleep to serve another request, the HttpContext of the factory changes to the second requests HttpContext. This means that the first request will work on the second requests HttpContext when it wakes up. This is bad news if you are dependent on the HttpContext in your custom controller factory.

The lesson is this: you have to do at least one of the two actions below if you want to access the HttpContext in your custom controller factory.

1)

The problem occurs when you set your controller factory like this (normally in the global.asax file)

1

ControllerBuilder.Current.SetControllerFactory(new CustomControllerFactory());

If you send in an instance lik this, it will be the only instance of your controller factory, and this is where the HttpContext-concurrency issues arrive in the first place. What you can do, which will take away all the concurrency issues is to send in the type instead of an instance, like this:

1

ControllerBuilder.Current.SetControllerFactory(typeof(CustomControllerFactory));

The drawback to sending in the type is a) your controller factory will be instantiated for every request and b) you cannot send in anything to your instance (since you’re not instantiating it). This might not be a problem, and if not, you’re good to go.

2)

If you have to use one instance only of your controller factory, and you need to access the HttpContext for a request, you MUST use the HttpContext.Current-instance and not the RequestContext.HttpContext. The HttpContext.Current is as far as I’ve tested thread safe.

Not thread safe:

1

RequestContext.HttpContext

The thread safe alternative:

1

HttpContext.Current

I just found out that this is a bug

- Tore Vestues

The ASP.NET MVC framework has a default controller factory (DefaultControllerFactory) that requires all controllers to have a parameterless constructor. So, if you want to inject your dependencies to the constructor, you can’t do it. In addition, Microsoft suggests the following pattern to mock out the dependencies when testing:

The Microsoft way of testing

(Example from www.asp.net/mvc)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

//The Microsoft way...
public class GroupController : Controller
{
    private IContactManagerService _service;
 
    public GroupController()
    {
        _service = new ContactManagerService(new ModelStateWrapper(this.ModelState));
    }
 
    public GroupController(IContactManagerService service)
    {
        _service = service;
    }
    //...
}

In other words, create one constructor for the actual application, and one constructor for testing. It works, you get to test it, it’s not all that bad, but it just doesn’t sit well with me.

Take control of your controllers!

Don’t you like this either? Well, there is an easy way out of it. One of the really good things about ASP.NET MVC is that it is easy to configure. You can create your own controller factory and take control of the whole process. It might sound like a complex task, but it isn’t.

Let’s start with our controller, it has a dependency that is injected through the constructor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class HomeController : Controller
{
    private readonly Speaker speaker;
 
    public HomeController(Speaker speaker)
    {
        this.speaker = speaker;
    }
    public ActionResult Index()
    {
        ViewData.Model = speaker;
        return View();
    }
}

Running the website now, trying to reach this controller, will make the framework crash (”No parameterless constructor defined for this object.”). We need our own controller factory to make this work:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class StructureMapControllerFactory : DefaultControllerFactory
{
    private readonly IContainer container;
 
    public StructureMapControllerFactory(IContainer container)
    {
        this.container = container;
    }
 
    protected override IController GetControllerInstance(Type controllerType)
    {
        return (IController)container.GetInstance(controllerType);
    }
}

This controller takes in a StructureMap.IContainer and uses it to create all the controllers. It inherits from the DefaultControllerFactory and overrides the GetControllerInstance-method that is used to create controllers.

Now all we have to do is to tell the ASP.NET MVC framework that it should use our controller factory. To do that simply add this line in the Application_Start() method in the Global.asax file:

1

ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory(new Container()));

(Notice that we do not need to configure StructureMap since our dependencies are so easy to resolve. In a real world app you will most probably need to configure the container)

There you go. Using StructureMap with the ASP.NET MVC framework is easy!

Download the complete example here

-Tore Vestues

Microsoft decided that DbC should not be a part of the languages themselves, but rather it should be offered as a standard library. I think this is unfortunate. If it had been a part of the language, the syntax could have been more declarative, and it probably would have given DbC more power.

The problem with having DbC as just another library is that you do not get any keywords, it is not allowed to be as declarative as it could have been, and the syntax gets unnecessary verbose. And besides, if it is just another library then this is really old news. There are several DbC libraries available on the .Net platform already.

But Contracts is actually a bit more than just another library. I believe the Contracts-team, not being allowed (I suspect) to make it a part of the languages, really wanted the power anyway. And so they got creative, and did a couple of interesting things.

First, they made tools as a plug-in to Visual Studio, and these tools are there to support the library. Second they actually added post compilation. In Contracts, you define all the Contracts-library code in the beginning of the method for readability (making it more declarative). But for this to execute correctly some of the code (the ensure-part), has to be at the end of the method. What Contracts’ tools do is actually move that part of the code to the end of the method, after the code is compiled.

This is very, very interesting, and it raises the question: What is a library/framework? Normally it is just some code you can execute following the normal constraints of a language. What the Contracts-team has done is to extend the concept of what a library/framework is. They implicitly say a library/framework is both code and tools, meaning the tools can actually do some tweaking with the code after it has been written. In this case it is done for the sake of being declarative.

This means that when you create a library you get the power to add declarativeness to it, beyond the language. Now that is a very compelling concept! There are of course a couple of problems here. Creating these kinds of tools for your library is not a trivial task! Microsoft can do this because a) they’ve got the resources and b) because if all else fails, they can add support directly in the compiler, which they have already done on several occasions.

The pain here is of course, that Microsoft can do it, but you really can’t. It’s too much work, and you can forget about accessing the compiler. We as developers are not enabled to have this power.

I’ve been playing around with Boo for some time now, and I love the way Boo allows me to add keywords and to change things during compilation. My point is that Boo actually enables you to make frameworks that also incorporates tools the way the Contracts library does, and in addition it actually allows you to create keywords! And the best thing about it is that this is doable for all. It’s not very complicated. It really empowers us as developers to redefine the concept of frameworks.

If a framework can be functionality, tools and keywords then we enable us to write powerful, declarative, and less verbose code. Boo enables us. C#, sadly do not.

The very, very sad thing here is that during another session at PDC08, Anders Hejlsberg “hinted strongly” that such compiler extensibility will never, ever be available in C#.

To demonstrate “Contracts”, this is how DbC is implemented:

1
2
3
4
5

string GetDescription(int x) {
 Contract.Requires( 0<x);
 Contract.Ensures(Contract.Result<string>() != null);
 // Method body ...
}

You add a set of Requires and Ensures at the top of your method. The Requires-statements must be true at the beginning of the method, and the Ensures statements must be true at the end of the method. This means that the Ensures statements must be executed last. This is where Microsoft uses the post compilation to move that part of the code after compilation.

I have actually already made a little library for DbC in Boo, it’s very easy to do (probably only took me an hour or so to implement). This is how you say the same thing with my little library:

1
2
3
4
5

[Require(i<x)]
[Ensure(result!=null)]
def GetDescription(x as int) as String: 
	result as string
	// Method body ...

It’s got all the functionality of Contracts, it’s just as declarative (or probably even more), and in my own opinion it’s less verbose. And do not forget that it took me about an hour to implement the whole library! This is enabling developers to be more productive!

Why Microsoft does not want to enable us with this is beyond me. But regardless of Microsoft, there is nothing stopping you from using Boo!

-Tore Vestues

I enjoy learning different ways to solve (the same) problems,  and I strongly believe it is important to do that. Seeing other ways to solve common problems will help expand your mind as to how you can solve problems yourself. That’s why i found this meeting so interesting too. Maybe I will not use Prolog so much myself, but I can still learn from it’s way of thinking, and enrich both my thinking and my code written in other languages.

Prolog 

Well, back to Prolog. I haven’t really been introduced to Prolog before, so I enjoyed the introduction we got. Three things strike me with Prolog:

1) How different it is from other mainstream programming languages.  Here we have a language that actually does not contain an “if”-statement, and it still solves problems. I find that fascinating in itself. It’s a completely different way to solve problems.

2) How declarative and explicit it is about the (domain) rules. Given a well defined domain I would love to express the rules for that domain in Prolog. It’s really beautiful.

3) It must be a nightmare to debug. When your ruleset and dataset starts to grow, it must be a nightmare to debug and even worse to try to make changes to it.

Java and Prolog (jTrolog)

Given my observations about Prolog are “correct”, I believe Prolog can be a beautiful tool, but I think the domain must be small and specific. And given that many of us normally work on enterprise applications with not so small and well defined domains, maybe Prolog is not the thing.

But then again, what if we find smaller well defined sub-domains within those enterprise applications?

Enter jTrolog (or one of it’s equivalents). jTrolog let’s you define and execute Prolog in plain Java. What I see here is opportunity. Now we can still make our enterprise applications in Java, but all of a sudden we can introduce the elegance of Prolog for specific sub-domains.

When it comes to it, it’s ofcourse not just that easy to introduce Prolog in your next Java project. For instance, introducing a new language that probably no one else on the project understands well, will most often not be a smart thing to do. But such barriers are there to be overcome.

Expand the horizon!

- Tore Vestues

This has several advantages (and ofcourse some drawbacks), but what got me interested is that this will put focus back on modelling the domain objects. Like in real object oriented systems, this means that all the business logic is contained within the domain objects. I’ve seen more than enough systems where the business logic is entagled into the gui-layer, making these system highly coupled and less flexible.

I think Greg Vaughn has found the essence of Naked Objects when describing it like “..primarily a design and requirements gathering tool, and secondarily a UI framework”. TDD looks like a way of testing, but the real power of TDD is actually how it drives the design of the system. The same with Naked Objects. It’s not primarily a way of making gui fast. The point with naked objects, as with TDD, is that it is drives the design of the system, and gives us a more object oriented design. Have a look at his blog “Naked Objects exposed”.  

I’ll do some experimentation with Naked Objects in the time to come, so stay tuned for more posts on the topic.

Tore Vestues