I finally managed to convince my colleague and partner in crime Patrick De Boeck to start blogging. Patrick is an external consultant and one of the members of the team I'm working with on a security project. Besides that, he's a very smart guy. Warm up your feed reader and subscribe to his blog.
Last year, I blogged about Test Data Builders here and here. I still use them heavily in my unit tests for creating objects with test data. Heck, I also use this pattern for fluent interfaces in production code. Here is a simple example of this approach:
public class CustomerBuilder { public String _firstName = "Homer"; public String _lastName = "Simpson"; public CustomerBuilder WithFirstName(String firstName) { _firstName = firstName; return this; } public CustomerBuilder WithLastName(String lastName) { _lastName = lastName; return this; } public Customer Build() { return new Customer(_firstName, _lastName); } }
This fluent builder class can then be used this way:
Customer customer = new CustomerBuilder() .WithFirstName("Homer") .WithLastName("Simpson") .Build();
A while ago, Greg Young started a series of blog posts on DDDD (Distributed Domain-Driven Design), which I can highly recommend. Make sure to catch up now you still can because I think that he has a lot of stuff coming up, which I'm really looking forward to.
Anyhow, Greg had a couple of posts on fluent builders, which you can read here, here and here. I noticed an interesting approach in the way that the target object is built. Here is an example of this approach:
public class CustomerBuilder { public String _firstName = "Homer"; public String _lastName = "Simpson"; public CustomerBuilder WithFirstName(String firstName) { _firstName = firstName; return this; } public CustomerBuilder WithLastName(String lastName) { _lastName = lastName; return this; } public Customer Build() { return new Customer(_firstName, _lastName); } public static implicit operator Customer( CustomerBuilder builder) { return builder.Build() } }
which results in the following usage:
Customer customer = new CustomerBuilder() .WithFirstName("Homer") .WithLastName("Simpson");
Adding an implicit cast operator to the builder class makes that its no longer required to explicitly call the Build method. I keep the Build method around for backwards-compatibility reasons or in case I ever need it again (violating YAGNI in the process, I know, I know). I find that adding the implicit cast operator adds to the readability of the fluent interface, don't you agree?
I think I'm going to be brief about this one. Everything you ever heard or read about this book is true. If you don't have this book already, then go get it right now because you are missing out on a lot of essential stuff. Although most of its content has been scattered around in many blog posts over the last couple of years, I learned a lot of new things.
What strikes me the most about this book is the fact that it has been published in 1999 (yes, almost an entire century in IT years). The content is far from outdated and could still be marked as innovative. I definitely know some co-workers and other people who could benefit a tremendous deal by reading this book.
The book is built around 46 short, self-containing sections with 70 different tips that will guide you to become a better programmer. The topics on orthogonality, reversibility, the DRY principle and the Law of Demeter really struck a nerve.
If you are serious about your profession, then you got to have this book and read it from cover to cover. There are only a few books that I want to reread at least once a year (PoEAA, DDD, etc. ...). This book has now joined the club.
The first alpha version of NHibernate 2.0 has been released some time ago. Oren has put a nice overview of the new features and the bugs that are solved for this first drop. In spite the fact that they put the word 'alpha' in the version name, it is actually RTM quality!
One of the great new additions is the on-delete attribute of the key element for mapping collections.:
<set name="Permissions" inverse="true" cascade="save-update"> <key name="Authorization" on-delete="cascade"/> <one-to-many class="Permission"/> </set>
This particular feature solves the issue I've had with one-shot deletes on inverse collections (which I described here). Configuring it this way ensures that NHibernate relies on database-level ON CASCADE DELETE foreign key constraints. This implies that when an object with a collection of child objects is deleted, a single DELETE statement is used to remove all children at once instead of individual DELETE statements for each child object (which are called orphans at this point).
There are some things that you have to take into account here. First, this option bypasses NHibernate's optimistic locking strategy for versioned data. Second, make sure that you configure cascade="save-update" instead of cascade="all" to prevent NHibernate from performing delete cascade checks. This is important when lazy loading is enabled for the collection because it prevents that NHibernate loads one-to-many associations into memory.
I'm really excited about this new release. Kudos to the men and women who have put so much effort in building such a wonderful ORM solution!
Till next time
Man, I really want this book! I've added it to my ever-growing book list.
Earlier this week I was in a meeting were someone stated that it was better to write your own IOC container than just using an existing one (the most excellent Castle Windsor in this case). I was just baffled to hear such statements.
The argument for writing your own container was simplicity and the learning curve for new developers on the team. I strongly disagree.
I can't think of anything simpler than downloading an existing IOC container that has a near flat-line learning curve, like the Castle Windsor container. About a year ago, I introduced it into the team. No learning problems whatsoever. Just read two blog posts about it and you are on your way
But the main reason I disagree is that I strongly believe that we have to provide business value instead of writing yet-another-IOC-container. We have to solve the problems of our customers. They simply don't care about IOC containers.
Scott Hanselman has a nice list of Dependency Injection Containers. Pick, choose and get over it!
Did I already mention that the members of the team I'm working with are just amazing! No? Well, they are. Yesterday, when we were at the VISUG session on WCF, I realized we are all professional learners. Just being proud to be a part of a team of craftsmen who care about what they do.
From each of these technologies I have a book laying around on my bookshelf somewhere. For WF, I have bought Essential Windows Workflow Foundation about 1 year ago. Since then, I've read the introduction about 15 times. After reading the intro, I always put it back on the bookshelf again. Every time I did this, I asked myself the question whether I needed something this complex for solving such a simple problem. I mean, how hard is it to write a state machine in code that you need a designer to do it?
Some time ago, I was in a meeting discussing yet-another-self-developed-GUI-framework. During this meeting, the use of Windows Workflow was demonstrated for handling page flows. When showing this in Visual Studio, it literally blew up taking Visual Studio down with it. Then I realized for the final time, that a Windows Workflow or Biztalk solution is too complex for solving the simple problems it was designed to solve and just too simple for solving complex problems.
What is wrong with mouse-driven development you may ask? Besides the fact that it is not productive (ask JP about this), there is one major problem with using a graphical designer: it only serves the needs that its builders have incorporated. The moment you are in a situation that falls outside the main scenario's, you are out of luck. Add to this fact that graphical designers are typically very narrow in scope.
Now, I can prove this. At my current employer, I already rewrote two unmaintainable Biztalk applications that were written by drive-by architects. These Biztalk applications were very unstable. Developers and infrastructure people were literally terrified just looking at them. How on earth did I manage to refactor a complex Biztalk application with a flow that doesn't fit on 5 pages and that sends and receives messages from another component using remoting? Well, first I needed two weeks in order to figure out what the hell it was doing (so far for the documentation argument in favor of WF). Then, I wrote a console application in about 3 days with 200 lines of code. This console application had one single minor bug on the first week after it went into production (I did something wrong with a Mutex: just my stupid fault). No more problems and issues were reported until this very day. Simplicity prevailed and it felt sooooo good!
After reading Workflow software: I'm calling the bluff on Leon Bambrick's blog (a fantastic post I must say), I'm definitely pulling the YAGNI card on WF and Biztalk. I'll also be moving the WF and Biztalk books from my bookshelf to a box on my attic, hoping that I'll never need them throughout my further career. Whenever I see or feel the need for using WF or Biztalk, I'll immediately start looking for a much simpler solution.
Yesterday evening, some team members and myself went to a session about Demonstrating WCF: Beyond the endpoints. The speaker was nobody less than Juval Lowy of IDesign. I'm not particular a newbie when it comes to WCF (although this post lets you believe otherwise), I really had a nice time. It's very clear that Juval is a trained speaker. However, the overall message of WCF as a silver bullet didn't quite catch on to me. Juval is a really smart guy. Therefore, he should know better :-). There are no silver bullets and no universal truths. I must admit that Microsoft did a remarkable job with the first version of WCF. One would almost believe that Scott Gu had something to do with it. But at the end of the road, WCF is one of the many tools in a developers tool bag. Tools can only take you that far but not to the end. Again, I had a really nice time. Kudos to the Belgian Visual Studio User Group.
David Starr from Elegant Code asked me whether I wanted to join his blogging group and I accepted. From now on, I will be the first European Elegant Code blogger.
I want to thank you my dear reader for keeping up with me. I promise that this blog will not go dark as I will be cross-posting all future content. So, no need to update your feeds. Be sure to also subscribe to the Elegant Code feeds as the people over there are both very nice and really smart.
