Larry Wall truthfully said the best virtues for a programmer are laziness, impatience and hubris. Sometimes you ignore these virtues when you get bored, you start to do stuff you know you shouldn’t, and your laziness doesn’t balance your hubris.

My new virtue that I’m going to work hard on is, ironically, laziness. KISS is the new methodology for me to follow: Keep It Simple, Stupid for design, YAGNI: You Aren’t Gonna Need It for architecture.

As a developer I think it is important to write the API so that it is usable and easy for a junior to understand.  Fluent is one way to do it, but it isn’t necessarily the only or best way!

Some places where I found Fluent difficult to use was if I needed to provide two parameters to an underlying service.  For instance its not uncommon in DotNetNuke to have to provide a User ID and a Module ID to one method call.  A Fluent Interface might say DoSomething.ForUser(userId).WithModule(moduleId), but that means storing the userId.  And to prevent the user from doing DoSomething.WithModule(moduleId).ForUser(userId) you would have to do some tricks with interfaces, and that is just not fun or easy for another developer to understand or use!

Sometimes it makes more sense to DoSomething.ApplyToSomthing(moduleId, userId) – it just does.

Of course, there are always tricks like Func<T> out there that we can use.  Because Func<T> is a .NET Framework feature I would expect another developer to understand how to use it, maybe not a raw cadet just out of school, but the documentation is there on MSDN for us to learn from.  Still I would probably have to define a class and use a lamda expression to use the method.  Lambdas are awesome for condensing code into readable chunks, but DoSomething.Using(p => { p.ModuleId = moduleId, p.UserId }) feels unwieldy to me. It makes a lot more sense in FluentNHibernate than it does in a small API or wrapper because you’re creating configurations and large sets.

So I’m going to be careful with my API designs and continue to make them usable.  After all, the best developer is one who’s code is readable and usable when its done.  And the best code does what it is supposed to but is maintainable by a noob.

This project was a pretty good one.  Even though we put the application into production, the customer didn’t have enough money to keep me on long enough to finish the project in a state I would have been more happier with.  There were a few reasons for this I think: 1) the customer did not have a clear enough spec, in his mind, before I started, 2) the customer was too busy with other projects to give me enough attention and direction with the design, 3) the customer was too busy to help me get the application into a User Acceptance test site earlier than two days before the contract expired.  If we had a little more time, maybe one more month I think we could have turned the application into something excellent, and I could have seen it in use long enough to know if my design assumptions were good ones.

That said, I did spend a lot of time with one of the Users who was a database modelling expert.  I did learn a lot from him, and he really helped me understand more about what they were expecting as a customer.  Unfortunately he worked in another building, so access to him was severely limited too.

Another success was that this was my first ASP.NET MVC project to be deployed.  It was also my first use of NHibernate, which I also thought was very successful.  I also used jQuery and jQuery UI extensively for Web 2.0 stuff like dialogs (death to window.open!) and AJAX.  Those things were a lot of fun.

I also got to use a of new architectural planning and design (Domain Driven Design) pattern that I learned from a talk given by Donald Belcham (aka The Igloo Coder).  I’ve been reading the book by Eric Evans as well.  This definitely seems like the new way to go.  DDD is about modelling your application and also about understanding the client’s needs.  I’m really impressed and eager to use it in future projects and products as well.

NHibernate is documented better than I originally thought if you look at nhforge.com, not at the hibernate site.  It also does some nice schema generation based on your mapping.  You still have to go through “XML Hell” to map the site, unless you use another mapper or FluentNHibernate (which does the mapping for you in code) or another tool.  As an ORM SubSonic feals cleaner and quicker since it generates the ORM classes from the database, where-as NHibernate generates the Schema from your mappings and ORM classes.

Generating the schema in NHibernate, even with Fluent-NHibernate, seems to take more work than generating the classes in SubSonic took.  However, it’s still quite simple.

Better support for Oracle was one of the primary drivers for me using NHibernate for this project, but after making the switch I’ve found a lot more interesting stuff, including an exciting ecosystem of NHibernate addins, plugins and updates.  I think it really appeals to the gadget geek in me.

The other thing that kept me thinking about NHibernate is the sheer number of other blogger / developers out there are using NHibernate!  After I started looking I was surprised to see how many blogging developers actually used NHibernate for their projects.  So not only do I feel like I’m in good company right now, but there are also a lot of people out there with good advice on best practices.

So, I’m taking another look at NHibernate right now, and I might post on it again later!

In the .NET world there are two powerful ORM tools out there, NHibernate and SubSonic.  NHibernate is based on the successful and popular Java EE ORM Hibernate.  SubSonic is an entirely new ORM developed in the Ruby on Rails ActiveRecord development model, with some nice .NET 2.0 features like Controllers that you can use with ObjectDataSource controls.

For a recent project I quickly evaluated both software tools, and I’m publishing what I learned here.

Setting up NHibernate:

The NHibernate Object/Relational Mapping is setup using XML files.  If you’re using the 3.5 Framework you can use a fluent interface instead (i.e. code the mapping in C# instead of XML).  I didn’t find a tool that generated the XML or interface automatically for you, but there must be one out there.

Changes to the database require changing the mappings, which means digging through XML.

Setting up SubSonic:

SubSonic mappings are generated via an external tool called SubCommander run from the tools menu.  Any changes to the database require regenerating these mapped classes.  SubCommander connects to your database, reads the Schema and generates O/R classes.  The O/R classes are Partial classes in C# so that you can create methods for the classes that won’t get overwritten by the tool each time you write it.

Changes to the database require re-running SubCommander (which can be done via the IDE).

The SubSonic team has also come up with some great videos to help you get started.

Migrations

The big thing that sold me on SubSonic was the new Migrations feature.  It uses a Ruby on Rails style migrations tool to help keep your database versioned.  It’s really excellent for a first generation tool.  It’s missing a few things, like it’s hard to set Unique Keys, but otherwise it is excellent.  This is also the first .NET Migrations utility I’ve found.

Migrations are one of the easiest ways to keep your database versioned, which has always been a problem for me when updating Test and Production databases.

Conclusion

I ended up selecting SubSonic for the following reasons:

1. No XML configuration files (running a tool is much easier, IMHO)
2. Migrations
3. Their excellent video tutorials and directions on their website