There has been some discussion recently on the Castle about Aspect Oriented Programming* and their usage in production applications. I thought about using aspects for logging & security in my current project. But I decided against it. The reasons varied from not wanting to add more new stuff to an already complex project, other developers who would use the code, and ease of debugging/testing.

Instead, I used this approach:

The Container class is the central axis of my project, it binds together many services and allows easy access to the functionality of the application. The IRepository<T> interface is a generic interface for accessing and saving data, but with a twist. The nice thing about this approach is that I can specialize for each case independantly, and yet use a common approach where it is needed.

Okay, enough with the buzzwards, what does it mean? It means that I can use this interface for objects that I create I persist using ActiveRecord/NHibernate, for values from a resource files, etc. I'm using it extensively to avoid having to special case my code for each and every object type that I want to use.

An advantage of this approach is that I can now use decorators to provide the usual benefits of AOP. I have decorators that handles security, logging, transaction etc. I find that it is much easier to explain to people what is happening that way, since I can avoid telling them to ignore the man behind the curtain.

Two personal stories, before the end:

• I had a bug in my decorator, where I leaked a transaction. It took me a while to figure out what was happening, (random errors about timeouts because the relevant rows were locked), since I never even looked at the decorator. When I debugged it, it suddenly put me in code that I recently chucked off as complete, and it was a two minute fix to do. I can imagine how hard it would have been if I couldn't debug that, or that it would happen completely transperantly.
• I've a ineresting security problem, I need to check two permissions (and two seperate actions) for a single action. I'm not sure how I would handle that using aspects, but I'm planning to create a specialized decorator for that case, and the rest of my code will remain blissfully unaware of it.

This is not meant as an attack on aspects. If you've been following my blog for a while, you probably figured out that the less I need to do, the happier I am. Aspects certainly provide that, but they come with their own share of problems, which I'm not ready to deal with right now. Decorators are well understood and easy to explain, and it's very easy to generate the skeleton code via ReSharper to delegate to the next item, and add the custom operations that I'm interested in.

* Just to note, Aspect# is a Castle Project.

I'm very partial to safe code, so I really like the using() statement in C#. The problem with this statement, however, is that I want to do different things at different times, which require different disposing semantics from the same class. Here is an example from Rhino Mocks:

I'm using the using() statement to allow easy scoping of the behavior. I find the code far more readable this way. The problem is that I need to create a class that implements IDisposable, while the action that I want is a single line of code. For this purpose, I created the DisposableAction:

The usage of this class is simple:

And then you can call it like this:

Simple, safe, and it doesn't require of me to write any more than neccecary.

There is a new build out, build-210, of the greatest boost to productivity since the syntax coloring :-D

Go get it here. It is mildly frustrating, to put it mildly, to get almost all the features that I so crave, only to put them away again because it's still alpha. What is cool is that you could actually see it improving every week or so.

Take a look at this:

In the case, "type" was a value that I got from MethodInfo.GetGenericArguments(). It's an unbound type, and it's not null, as you can see. It took me a while to realize what is going on. The System.Type type is probably configured to display in the debugger its FullName property, which is null in this case.

Until I figured it out, I was certain that GetGenericArguments() is returning null for unbound generic arguments.

Here is an interesting question, I've a couple of UI Controls, which are remarkably similiar, and share the same base class. The only differences are some strings that are displayed to the user, and the result of some action. I'm using the controls as a way to create instances of a base class, so you may think of them as a UI Factory. The issue is generating the following UI:

Right now the form is responsible for loading the data, and the control is reponsible for creating/saving & displaying it. In many cases, all I need to do is to change the names of the fields and the type that is created. I can create some sort of a base class to do it, and I can probably do it cleanly, but is it worth it?

Right now I simply copy & pasted the code and made the neccecary changes. The changes I needed to do are minor, but they represent different objects entirely (a German Shepherd vs. Poodle, for instnace). The form sees all of those controls as a single base class, and doesn't care which object it creates or display.

What do you think?

After nearly a year, we've a new version of NUnit, 2.2.3. You can find the details in the release notes.

But they added a bunch of really cool asserts,  IsInstanceOf / IsAssignableFrom / Contains, etc. There is also a new StringAssert, which is also nice.

Today I had a bug, a very nasty one. This bug was quite innocent, is looked like this:

A pretty simple code, isn't it? The Black() method is a static method that just creates the object (its purpose is to simplify instansiating the object, nothing more). But instead of getting a poodle, I was getting a generic dog!

The sad part about it is that it worked when I was trying to save it, and only bombed when I tried to load it, meaning that I got the exception on a totally unrelated place in my code. After indiscrimantely accusing (roughly in this order):

1. Castle.ActiveRecord
2. NHibernate
3. Sql Server
4. TCP Stack
5. The Cat
6. The Little Green Men
7. That Guy Over There

I sat down and really looked at at, and I still couldn't find a reason that this would give the end result. The Poodle class obviously had a static Black() method, in which a Poodle was created and returned. Why was I having this problem? What did I do to deserve this?

Well, I did something very stupid, let's see if you can figure this out from the code:

Do you see the problem? I was using the wrong overload, and the method that the compiler called was Dog.Black(). Finding out that it was my fault didn't go very well with the Cat, I can tell you that.

Anyway, the lesson is that you should be careful about "overriding" static methods, because they can bite.

For the last week of so, my life has been relatively free from annoyances with web projects. I've learned to work around most of the issues, and except from the slow build times (Ctrl+Shift+B is hardwired into my left hand now, and I can't really change it, anyone has a config editor for muscles?) and the slower refactoring times, I'm happy.

I just adore refactoring, and I use it all over the place, and the slowness of refactoring in each and every time I make a change in a solution that includes a web project is pure hell. So I'm facing a big refactoring phase, and I'm not really ready to turn it into half a day looking at a progress bar crawling all over the screen.

I thought to remove the web project from the solution, refactor, and then add the web project back, and fix by hand any errors that I created. Not a problem, right? But the moment I added the web project back into the solution I had to face again all those issues about web projects again. It forgot all about the project references that I added to it (since they are managed in the solution level, and I deleted those when I removed the project). But the highlight moment of the ordeal was when I tried to add the references again.

A short explanation about my project.

• The Web Project needs Project A
• The Web Project needs Project B
• Project A is dependent on Project B

When I tried to add both A & B to the web project, I got an error, saying that project B is already added. The add reference dialog also copy all the dependent dlls to the Web Project Bin, but I'm not sure how it handles this situation. It's a drastic change from the way the rest of the .Net framework works, since it will usually error on situtations like this, where the child project is referenced, but a parent project is not. I understand what is happening behind the scene, I just really don't like it.

In order to add Project B, I needed to remove Project A, add Project B, and then add Project A. By then I was so busy with web project stuff that I totally forgot that I refactored, and I could understood why I was getting build errors. (Worse, for some reason double clicking them didn't brought up the page unless it was already opened).

When I finally did, it was a smack-your-head moment, two minutes fixes, and clean build ever since.

An interesting post on The Moth on which of the two you should prefer?

• new Blah<SomeType>();
• new Blah(typeOf(SomeType));

Personally, I like the first one better, but I can see the benefits of the other one as well. I'm currently have a faint smell regarding this with a method calls that look like this:

I could've written it the other way, like this:

But it's shorter and clearer (to me) the first way, and I can do some compiler time validation on it. Beyond that, even though there are some dynamic stuff going on there, it looks static, and that is important. I'm using this pattern to abstract my whole data acess strategy, and it's working quite well so far. I get different repositories for different types, and I can put custom behaviors during save/load quite easily (validation, business rules, etc).

I'm even using this to get stuff that doesn't come from a database, in a way that is totally transperant to the application. In my opinion, the generic version is better, since it looks like it's part of the language.