Rethinking thinking

Rather than talking about rethinking web architecture, we are actually talking about rethinking our thinking and practices when designing web architecture. So, although we do give a concrete example, this is not the one new architecture. The main points we’re trying to convey is that you should keep it simple (often much simpler than we normally do) and that architecture should evolve (adding only when you have to, when you have to). The example shows one way of doing that.

Growing architecture

Letting software and architecture grow as we learn is for me simply being agile, but my experience tells me that although most of us consider ourselves agile, we have a hard time wrapping our heads around what that actually means when it comes to architecture. Being agile when it comes to architecture, and being able to grow good architecture takes a lot of skill and knowledge, and let it be clear that when we talk about simplicity we do not say throw away everything. We say reflect on every choice you make.

Developer productivity

Our presentation also take a critical look at the typical three layer architecture which, a bit to my surprise, was known and used by almost everyone in the audience. The critique is mostly about productivity, or rather the lack of it. Pushing data through such an architecture is often a pretty costly affair. An interesting point is also that with this architecture we violate the DRY principle at least ten times for every piece of information in the system (that is stored in the database). I spend a few minutes explaining that one. Have a look yourself.

Some of the feedback we got after the presentation suggests that this talk have sparked a few discussions. That is great!

You can watch the presentation here.

The NDC 2011 website is here.

- Tore Vestues

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

This time my talk will be in Norwegian.

My talk – Javazone 2010 – Agenda

I recently ran into an example in Glue where I refactored towards LOD. I will share my thoughts on that here.

The problem

I am working on a new feature in Glue. In order to make room for that feature, I had to do some refactoring, to make it smoother to add that feature. What I found during the refactoring was this line (in the Mapper-class):

1

mapping.Relations.GetRelationsTowardsRight()

I found it because I already had some trouble with the Mapper class’ dependency on the Mapping class. I realized that I was exposing a lot of information, Mapper shouldn’t know about Mapping. This dependency made my refactoring job bigger. I strongly believe that objects should know as little as possible.

This is a good example of breaking LOD. I think breaking LOD isn’t always a big offense (Martin Fowler suggests we rename it “Suggestion of Demeter”), and I don’t think doing it here is my largest mistake. But now a new feature had brought the need for some refactoring, and at this point applying LOD seemed like a good idea. So it’s not only a question of where to apply a pattern, but also when.

The solution

The Mapping class is a kind of facade to the rest of the system. It is an attempt to make the API as simple as possible. That means it handles the creation of some objects. In our case this is how Mapping creates Mapper objects:

1

var mapper = new Mapper<LeftType, RightType>(this);

(Notice how Mapping passes itself in to Mapper). Mapper gets what it needs by calling:

1

mapping.Relations.GetRelationsTowardsRight()

Mapper gets a RelationContainer (the Relations property) from Mapping.

This breaks LOD. There is a simple fix in this case. The code passes a Mapping object, while what the Mapper wants is a RelationContainer. We should only pass the object it needs (in the Mapping class):

1

var mapper = new Mapper<LeftType, RightType>(Relations);

The Mapper now gets what it needs by calling:

1

relations.GetRelationsTowardsRight()

It’s fixed!

This way we have lowered the coupling, making Mapper unaware of Mapping, meaning that now it can access only what it needs, not a whole lot more. For me it is important that objects know as little as possible, and now it knows a whole lot less. It doesn’t care (or know) where the RelationContainer comes from. That isn’t its concern, and shouldn’t be either.

(The Law of Demeter is a rather academic specification of who is allowed to call who, specified here. Basically what it boils down to is that you shouldn’t ask for other objects from an object, and do an action on that. Or in other words, you should just use one dot per line.)

Not the “standard” solution

This solution is not how one normally is advised to resolve the breaking of LOD. Normally you’re supposed to hide the inner object. In this case it would mean that Mapper should be unaware of the fact that Mapping contains a RelationContainer, it should just ask Mapping to get the relations (a concept called encapsulation, it’s pretty standard object oriented thinking). Like this:

1

mapping.GetRelationsTowardsRight()

That’s a smart solution, if you’ve got the right problem. That solution enables Mapper to only know about Mapping, and none of its collaborators (hiding the RelationContainer in this example).

But the problem we have here is slightly different. What I found here was that Mapper should not know about Mapping at all. Mapper should only concern itself with the relations, and in this case Mapper should only receive the RelationContainer to work with. So the problem was that we depended on the wrong object altogether, not that we had the right object, and had to know about its collaborator. A subtle, but important difference. It’s important to be aware of what your problem is in order to find the right solution. It’s not always as easy as choosing the “standard” solution.

Reflections on Law of Demeter

LOD is just a concrete set of rules that aims to help writing less coupled code. You can do this without even knowing about LOD. In our case, focusing on separation of concerns can yield the same effects. As can sound object oriented thinking, like hiding as much as possible (not exposing things through properties or getters), focusing on knowing as little as possible, applying “Tell, don’t ask”, and so on.

The problem with concrete rules like LOD is that it works great if you understand the intention, but if you do not, you’re probably going to apply it wrong. And if you understand the intention, often you can get the effects without even thinking about LOD.

For me, I like the intention of LOD , but I do not think about it that often, as I use other guidelines to help me yield the same result. On the other hand, knowing the LOD principle have helped me on several occasions, as in this example, to see clearly what is going on.

Also, if you need to justify a style of programming that is heavy on mocking, LOD is an often used argument.

This refactoring is checked in as changeset 52023 in Glue. Compare that and the previous changeset to see what was done.

- 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

That means I am a C# MVP, and I am very proud of it!

I feel it is important for me to contribute to, and learn from, the technical communities around the world, and therefore I’m honored by receiving this award for my contributions. I will do my best to continue to contribute to the communities in the time to come, and I know I will learn a lot from them.

- 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

My talk titled “A Style of Programming”, was filmed and is already online.

You can find it here.

Most of the other talks from the conference can be found here.

- Tore Vestues

Xp2010 was a great event by the way, and you can find other talks here.

- Tore Vestues

Ndc 2010

I’m very proud to announce that I will be speaking at the Norwegian Developers Conference 2010 (track 6, day 3, 16:20).

My talk is named “A Style of programming”:

“This talk describes a set of coding principles that constitutes a style of programming that focuses on ease of coding, ease of changing the code, and ease of testing the code. The presentation aims at helping programmers understand how the principles relate to actual code. Every principle is made concrete through examples. This style of programming is influenced by leading object oriented and agile developers, and it is perfect for applying on object oriented languages such as C#.”

Hope to see you there!

- Tore Vestues