I've been doing quite a bit of messing around with Rhino Commons the last few days.  I really like the ability it has to let you use Castle ActiveRecord without needing to derive from a base class, to provide access to objects through the Repository<T> class, and to not have to use NHibernate XML configuration files (yuk).

However, one of my struggles with it is that the library assumes that you are in a web app, as you must derive your application class from the UnitOfWorkApplication class, which is itself derived from HttpModule.  Well, this is a problem if you are writing a console app, service, or other non-web application, as the UnitOfWorkApllication class does a lot of setup in its constructor that is needed to use all of the cool features of the library.

So, after much diving into the source code to figure out what's going on (there is almost no documentation on how this library actually works), I was able to write my own application class, appropriately called GenericUnitOfWorkApplication, which can be used in non-web apps (specifically, console apps).

As an example, here is my sample console application which show you how to use this class, while storing a new domain object in the database and then iterating across all of them:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using Model;

using Rhino.Commons;
using _42Spikes.Rhino.Commons;

namespace TestConsole
{
    class Program : GenericUnitOfWorkApplication
    {
        static void Main(string[] args)
        {
            new Program().run();
        }

        private void run()
        {
            UnitOfWork.Start();

            Repository<User>.Save(new User("Mike Heydt"));
            
            With.Each<User>(
                Repository<User>.FindAll(), 
                t => Console.WriteLine(t.Name));

            UnitOfWork.Current.Dispose();
        }
    }

    public abstract class With
    {
        public delegate void operationdelegate<T>(T o);
        public static void Each<T>(
            IEnumerable<T> objects, 
            operationdelegate<T> f)
        {
            foreach (T i in objects) f(i);
        }
    }
}

You can download this entire solution (short of the database) here.

What's going on there is that the Program class derives from my GenericUnitOfWorkApplication class, and when its constructor is run it does all the initialization of the Castle and NHibernate stuff that the UnitOfWorkApplication class does, minus all of the web stuff (like setting up things to manage unit of work mapping to ASP.NET sessions).

The down side of this is that the unit of work is not set up automaticaly, and you need to do it yourself.  Oh well, a small price to pay I think for this great functionality.

And I really like the brevity of this code and now much functionality it has in just a few lines.  Also note my use of a custom With class to apply a lambda function to each element of the database, which I think is quite nice syntax.

Just thinking out loud here, I still think that there are a few things things that I still need to do with this code:

1. I like that the original UnitOfWorkApplication would map units of work to the session automaticaly.  It's only a few lines of code up there, but it would be nice if this could somehow be automatic.  I think the solution to this is to use PostSharp to apply an aspect to specific methods that automatically create the UnitOfWork.  That would be cool.
2. This class is still a problem in an application like WPF where your app object needs to derive from a framework class, so this class is not really of use in that situation.  However, there is nothing magic about this class as it does not have to be your base class, you can create a singleton instance of it in your app.  All that is needed is the initialization code run in the constructor.

Which leads me to wonder about the use of AoP.  It would seem to me that you should be able to automatically inject this functionality into your application class.  I'll have to look into how to do that with PostSharp.

I'm starting a new project at a client tomorrow, and I think I'm going to go with a lot of Alt.Net stuff on it.  Specifically, I'm looking into using:

• Visual Studio 2008 SP1
• .NET 3.5 SP1
• PostSharp (for AoP)
  
• Rhino Commons (for simplifying access to NHibernate and such)
  
• Castle Windsor (IoC and DI)
  
• Rhino Mocks (Test Mocks)
  
• NHibernate (Database Access)
  
• MbUnit (Unit Testing)
• NLog (or log4net)
  

I actually would really have liked to try Linq, but I'm using an Oracle database so that goes right out the window.  I don't even want to try to use EF as I don't need that much of a hammer on this...

I've only got a nominal amount of database reading and writing, so I think I'm going to front this access with the Rhino Commons and Castle Active Record.  I really don't want to write any ADO.NET or NHibernate XML files, so this looks like a good way to go.  I also want to use DI to be able to inject either database mocks or actual data classes into tests.  I want to also be able to run this in disconnected mode, so some mock data would be great when provided through DI.

I've used MbUnit before, so I'm staying with that, although I'm going to move up to the new version which apears to have some more features.

The big thing I want to move into is the AoP model (as well as DI).  I just got the latest version of PostSharp installed and it worked great, at least with initial tests.  I'm big on logging in the applications, but I really have been wanting to do cross-cutting instead of explicitly coding it all over the place.  This looks like it will solve this nicely for me, as well as combined with some DI I should be able to inject null loggers into the system for optimization.

I was (am) listening to the Alt.Net podcasts today.  I just came across this podcast series last night.  I don't know why I didn't hear of this before, but perhaps it's because it's relatively new as it's only been publishing for a few months and is up to 8 episodes.

At the same time, I'm on a three hour train ride from Baltimore up to Connecticut to talk to a potential new client (to be specific, an interview).  The combination of brushing up on some things I don't do on a daily basis in case I'm asked about them, as well as some concepts discussed in this broadcast has brought me around to something that's on my mind relatively often but that I've never written down...

What are the key concepts in software engineering, as of today, in July 2008?  This is not meant to be an complete list, or that the items exhibit complete separation of concerns relative to each other.

Here my initial stab at what I think are the things you must exhibit to be an exceptional architect at this time:

• Domain Driven Design (DDD)
• Test Driven Design (TDD)
  
• Software Evolution / Continuous Improvement
• Patterns, Patterns, Patterns
• Dependency Injection and Inversion of Control
• Policy based programming
• Aspect Oriented Programming
  
• Doing things as much in a declarative nature as possible
  
• Domain Specific Languages
  
• Separation of concerns
• Design by contract / Interfaces
• Service Orientation
  
• Transparent translation of domain to persistent store
• Mocking
• Parallelism
• Caching
• Factories
• POCO 
• Event Driven Design
• Orchestration
• Rules
• Logging / Instrumentation
• RDBMS design
  
• Keep it simple stupid
  

I'm going to come back and expand this list as well as elaborate on each.

I found this "book" yesterday after Scott Hansleman twittered about it.  I just started reading it and just a few pages in I already felt inspired to start discussing it.  This is purely based upon some initial statements made about YAGNI (You Aren't Going to Need It) and being in the ALT.NET frame of mind instead of the MSDN frame of mind.

I really enjoyed the initial statements on MSDN versus ALT.NET.  I really do feel that there is a big difference between these ways of doing things.  In the book, Karl quotes Jeremy Miller (who I used to work with) as stating "that the MSDN way is a practice of having too much focus on learning the API and framework details and not enough emphasis on design and coding fundamentals."

I absolutely concur 1000% with this statement.  I used to think this way, because that was, for many years, what I was told was the way to think.  There used to be a days when I used to know the entire Win32 API, and I was really proud of it.

Then one day I realized that this wasn't doing me very much good; it wasn't necessarily doing me much harm, but it was limiting me in that through the process of this type of learning I was unknowingly preventing myself from really seeing how to solve real issues in software that were important.

I don't know where or when it happened (but I'll guess is was about 10 years ago if not 5 or so years before that), I started to think in larger abstractions about the problems I was dealing with.  I started to think that, well, in my adventures in enterprise software development, that:

1. I wasn't really solving any new problems
2. All of this detailed knowledge wasn't helping me solve those problems any better every time I had to do it again
3. That there must be better ways of doing this

I don't know, perhaps you might say that was when the lightbulb turned on and I started to thing like an architect instead of a programmer.  That may be it, but I think its too simple of a statement.  And I'm not sure what I think about the moniker "architect" either, as I think today it presupposes things, both good and bad, that may not really be important either.

I guess what I'm saying is that after years of trying to solve how to do things better, it feels that it is to me exactly what Karl states about the philosophy of ALT.NET, which is to focus on alternate solutions and approaches to the MSDN way of thinking, and I'll add specifically that this is a way of using best practices learned through experience of the community to solve problems through knowing the patterns of how to solve the problems, and then worrying about the details of solving the problem only if there isn't a solution already available.

To me this is a very fundamentally different way of thinking about going about the things that I do.  I often get asked many times what are the specific method or so and so class in interviews, and I'm often like, "I don't know off my head, but give me a second with Google, or better yet, why know them when I can solve the problem with a better tool providing a solution to the overall problem."

See, I think this kind of stuff is just cognitive overhead, knowing all these details.  Over the years, instead of knowing all the details in memory, I've built ways of knowing how to look up the details at a moments notice.  And by defering to other tools (like Google, or open source projects, or patterns and practices) for storage of the details, I really feel like I have allowed myself to become more creative and at the same time more productive.  I've effectively become more atune to being able to solve the problem effectively, instead of just focusing on mastering the tools.

The thing that I wonder is if this type of reasoning can be taught from inception instead of having to learn through street smarts over many years.  I think that sometimes this can be, but at other times I think we're just so entrenched in software with mastering tools instead of mastering solutions using the tools.

I mean it still amazes me that in many places that I consult, or with people that I talk with in my field, that they just stick with this means of doing things the way it always has been done.  Its really an anti-pattern, and it's a difficult one for many to break.

For example, I once told another developer on a project that I was consulting for, in front of his boss, that when he was done with some code he was writing to integrate data between several systems, that I would like to write a unit test for this code.  This would be something that would be mission critical, and run every day, and I wanted to make sure that if we had problems with it that I could be able to prove the failure using the test so as to fix it and make sure we don't have that problem again.

Well, I was aghast by the reponse I got, almost before I even got the entire sentence out.  Testing wasn't important, and that I need not (and I mean that I am flat out not to) build that test, as there were more important things for me to focus on.

Well, the really amazing thing about this was that this piece of mission criticality was just run for the first time, with some dummy data, and that was apparently good enough to push it into production the next week without any additional testing or plans on how to handle it if it failed.

Guess what?  It failed.  And it failed hard the next week.  And the users were pissed.  And I got to write that test then.  And it was another 8 weeks until the users allowed us to try this again, delaying us several months when I could have put together preventative measures in a few hours of work.

So, where am I going with this?  Perhaps nowhere really, but it's stuff kicked into my mind in the first few pages of this book that I though I had to get out.  I do really think that we're moving into a new paradigm in the next 10 years with software, and I think that some of this is embodied with this contrast of MSDN and ALT.NET.  I just hope we as a community can make this happen.