ALT.NET Mailing List: YMMV

I finally caught up with my reading on the Alt.Net mailing list.  I can't say that I'm a frequent contributor to the group - I'm usually a good few days behind any conversation and also I'm still on the learning path myself so can't usually provide any answers.

Unfortunately the threads on the list seem to be degenerating into the same old Alt.Net catfights. There seems to be far too much "You're doing it wrong", or "you should be using pattern/technology/tool XYZ, anything else is useless".

What I would find more useful, and certainly more pleasing to read, would be along the lines of "I did something similar and used pattern/technology/tool XYZ, but YMMV"

For some reason this doesn't seem to happen on the other groups I read.  The BDD, DDD, TDD groups generally seem a bit friendlier.  I also recently joined the Agile Testing group and saw this on the introduction page:

We would like most of the discussion to be specific:
Q: "I am in situation X. I've run into problem Y. Does anyone have any advice?"
A; "I was in a very similar situation last year. We tried Z, and it worked OK."

Now that's more like it. 

Why ASP.NET is like Progressive Rock

I like Progressive Rock.  There, I've said it.  All out in the open now - nothing to be embarrassed about.

So I was quite amused last year when we were asked to develop an internal, bespoke application called Genesis.  What I didn't realise at the time was just how the development of the application would mirror the history of the group Genesis. The application was my first foray into many new techniques such as MVP (with web forms), IoC, NHibernate etc.  Here's how it went:

 

The Group	The Application
The Gabriel Years
Something different! A strange front-man (Gabriel) backed by some brilliant musicians (Banks, Phillips, Hackett) creating something new and exciting.	Something different! A strange front-end (MVP with webforms) backed by some brilliant technologies (NHibernate, Windsor) creating something new and exciting.
The Hackett Years
The front-man was a bit too eccentric and difficult, so Collins steps up to the mic.  The rest of the band really gel and produce some of their best music of their career.	The front-end was a bit too eccentric and difficult to maintain, so simple webforms are back in the frame.  The rest of the technologies really gel and produce the best development experience of the project
The Collins Years
The new front-man starts to dominate and it all starts to become familiar and mainstream.  The other two (Banks, Rutherford are still going strong but their contribution seems to get overlooked.	The webforms front-end is starting to dominate development with bugs and it's all starting to feel familiar and mainstream.  Windsor and NHibernate still going strong but I keep forgetting they are there as there are so few bugs.
Calling All Stations
Oh dear.  A brief flirtation with a new front-man.  He's quite good in his own right, but not really the man to replace Collins in this group.	A brief flirtation with Monorail.  It's great for new projects but it's too much effort to replace Webforms in this project.
The Present
Collins, Banks, Rutherford ticking along quite nicely - know what they're good at and quite happy to settle for a pay cheque at the end of the day.	Webforms, NHibernate and Windsor ticking along quite nicely and quite happy to release at the end of the day.
The Future
Definitely past it, and time to move on to fresh blood such as Frost*	Webforms are definitely past it and time to move on to Monorail/ASP.NET MVC

Book Review: .Net Domain-Driven Design with C#

Occasionally, an idea comes along that completely changes the way I think about developing software.  Eric Evans' Domain-Driven Design: Tackling Complexity in the Heart of Software was one of those.  As a database-first developer it suddenly seemed so obvious where I was going wrong. 

The only trouble with Evans' book is that it very much deals in the abstract.  Unlike other patterns books that give small snippets of code as examples, many of the DDD patterns in the book are left as an exercise for the reader.  Some people have tried to remedy this, such as Jimmy Nilsson with his book

Applying Domain-Driven Design and Patterns: With Examples in C# and .NET but ultimately that was a good source of information with very little source code. 

There is also much heated debate about how to implement these ideas online.  Some people believe that just having a class called Repository in your code makes it DDD, others seem to be drawn in by the endless possibilities of the Specification pattern.  There's very few examples of an end-to-end application though.
Tim McCarthy has bravely stuck his head above the parapet and written a full DDD example, and documented it in his book.  I've just finished reading it, and here's a quick review of what I liked and disliked:

 

The Good:

• At last, some end-to-end source code!
• The book wisely stays away from the religious ORM argument, and just implements a repository using standard SQL.  This allows more focus for the domain creation
• Because of this, other techniques that might usually be taken care of by an ORM, such as Unit Of Work, are created.  I think this allows a better understanding of what they are there for.
• I quite like the implementation of the Specification pattern he uses, as it is similar to the way I use it.

The Not So Good:

• The first criticism is actually not directed at this book, but rather the Wrox "Problem - Design - Solution" books.  This is the second one I have read, and both of them seemed to spend huge amounts of time describing the source code.  If I want to see the source I can download it from Codeplex. I think the space would have been better spent going into more detail about the process of design, the thought behind some of the decisions and maybe more detail on the evolution of the code. 
• As an example of this, on p70 McCarthy describes You Ain't Gonna Need It and then on p73 makes a class abstract because "who knows, later on having it as an abstract class might turn out to be useful".  Fair enough, it was useful, but not at that moment...
• Although I've also listed it as a good point, the SQL repository  can also be a bad point (you just can't win!).  I think most people will use some ORM in their solution, so this could be a bit misleading.  I wonder how easy it would be to do an NHibernate repository...

.NET Domain-Driven Design with C#: Problem - Design - Solution (Programmer to Programmer) ISBN: 0470147563 ISBN-13: 9780470147566

 

In summary, I would say that whilst Tim McCarthy has done a good job in bringing the idea of DDD to more people, the most benefit can be gained from downloading the code and studying it.  There's too much regurgitated code from the source in the text of the book, and the space would have been much better used to describe some thought processes along the development path.