While doing a code review of NMemcached it started to bother me just how much of the application was infrastructure and argument parsing code. It shouldn't be this way. So I decided to port the whole thing to WCF and see how it works.

Porting it wasn't hard, and significantly reduced the amount of code in the application. After updating all the tests and verifying that I fixed all the things I broke, I built an appropriate memcache client and started perf testing again.

As a reminder, native Memcached server managed to field 10,000 reads and writes in just 1709.6 ms. My own implementation got to the same point in 3144.5 ms.

The WCF implementation (note, the implementation and the benchmark are different, because of the different approaches, but the test is the same)...

Right now it is using net.tcp binding and it is at a lousy 7853.3 ms.

The code is available here, and I would appreciate any comments. I didn't even try to optimize anything with WCF, just set it to net.tcp and let it handle everything else.

One of the thing that you see some people agonizing about is what they should be exposed to the outside world. On the one hand, people have heard all about encapsulation, and how it is going to save the world. On the other hand, we want to expose functionality to the outside world, be it for testing or for advance usages of your software.

Something that I wish that C# had is the published alias to the public keyword, that would have expressed intent in a much easier fashion than just public.

That said, I found a very useful approach to handling this myself. Separating interface and implementation. Let us look at an example:

public interface ICommand
{
     void Init(string[] args);
     void Execute();
}

And an implementation of that:

public class MyCommand : ICommand
{
       public string Key { get; set; }
       public long ByteCount { get; set; }
 

       public void Init(string [] args)
       {
		// parse args to key & byte count
       }
}

Now, if I want to test that I am getting the right thing, I can, easily. At the same time, the published interface of this is ICommand, not whatever is public in MyCommand.

In situations where I have one to one mapping between interfaces and implementations (IUserRepository and UserRepository), this is even more pronounced.

I am a bit late on posting this, but I suggest taking a look here to read some of the community reactions to the issues we have observed in the Entity Framework.

I will let the document stand on its own, since there is no way I can be impartial here.

I would like to state something (which I also told the Entity Framework team in person):

If someone manages to come up with a kick ass OR/M solution that does what I need (allow me to create maintainable and flexible solutions and has the expendability points to be used on real world projects) and which I, personally, don't have to (help to) write, I would be utterly overjoyed.

I just read a few of my posts from 2004.

They are... an education. I forgot how I was then.

My project at the time was creating a writable configuration file API and rambling about bad OSS is.

This is just wrong:

I am writing some integration tests at the moment, using WatiN, and I am really enjoying the process. The last time that I tried to use WatiN it was in a WebForms environment, and it was... hard.

Using it with MonoRail is a real pleasure. Here is a simple test:

[Test]
public void Can_submit_new_values_for_webcast()
{
	browser.GoTo(appUrl + "webcast/edit/" + webcast.Id);
	var newTestName = "New test webcast name";
	browser.TextField("webcast_Name").Value = newTestName;
	var newDesc = "There is a new webcast description";
	browser.RichTextEditor("webcast_Description_Editor").Type(newDesc);

	browser.Button("webcast_save").Click();

	browser.Url.ShouldContain("webcast/view/" + webcast.Id);
	ReloadWebcastFromDatabase();
	webcast.Name.ShouldEqual(newTestName);
	webcast.Description.ShouldEqual(newDesc);
}

For a while, I was happy with this, but I have over two dozen such tests, and it is getting very annoying to remember what the all the names of all the fields are. The second time that I started copy & paste the ids from one test to another I knew that I had a big issue. How to solve this was something that I had to think about for a while, and then it came to me.

I can create a model for the interaction with the page, and test the UI through that. Here is my test model:

Using that, I could get my test to look like this:

[Test]
public void Can_submit_new_values_for_webcast()
{
	browser.GoTo(appUrl + "webcast/edit/" + webcast.Id);
	var newTestName = "New test webcast name";
	edit.WebcastName.Value = newTestName;
	var newDesc = "There is a new webcast description";
	edit.Description.Type(newDesc);

	edit.Save.Click();

	browser.Url.ShouldContain("webcast/view/" + webcast.Id);
	ReloadWebcastFromDatabase();
	webcast.Name.ShouldEqual(newTestName);
	webcast.Description.ShouldEqual(newDesc);
}

Not that big deal, you may say, but now I can just blaze through those tests, writing them with far less friction along the way.

This is especially true when you modify the implementation of the page, but not the interaction, in this case, you want to be able to replace the implementation in a single place (say, change the id of a control, or the type of a control), instead of all over the place.

I am quite happy with this for now.

Which should I use?

This:

Or this:

First, I really have to say that I had no control over this poster, it just came up and I had to put it here.

Let us just say that this is an encouraging development:

This has caused some hair pulling, this piece of code fails if I don't pass a webcast variable, even though it is properly guarded.

Once I convinced myself that yes, I was stupid enough not to cover this scenario, reproducing this in a test was very easy.

The solution is so simple I am posting the changeset here: