Toluu

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

My Topic Proposals for ALT.NET Seattle '09Today

ALT.NET Seattle is 6-7 weeks away, but it's not too early to think about what we want on the agenda. I enjoyed KaizenConf, but I'm looking forward to skewing the sessions back toward more technical content. 

My Topics:

• Using Language Oriented Programming in .Net
• Convention over Configuration in Real World .Net Projects and Tools 
• Wringing more productivity out of MVC web development
• Open Source alternatives to WF and WCF (or at least tools that aid in WCF usage)

What's yours?

 

 

Choosing the Constructor Function in StructureMap without AttributesYesterday

A longstanding complaint with StructureMap is that the way StructureMap selects a constructor function can only be overridden with an attribute.  Using attributes is now frowned upon, and other times is impossible.  StructureMap 2.5.2 (the version in the trunk that, knock on wood, I get released no later than Saturday) introduces a quick programmatic way to select the constructor function using the magic of Expressions.  This is an excerpt from the new StructureMap documentation I’m working up.  It will be much more readable on the website (next week hopefully):

 

 

StructureMap has always allowed you to override the constructor choice with an attribute, but increasingly, many people are unwilling to use attributes in their code for infrastructure concerns.  Other times you may want to override the constructor choice of a class that you don't control.  Either way, it would be useful to select the constructor function used by StructureMap to build a concrete code in the Registry DSL.  The syntax to do just that is shown below:

Let's say that you have this class (from the unit tests):

    public class ClassWithTwoConstructors

    {

        public ClassWithTwoConstructors(int age, string name)

        {

        }

 

        public Clas

A Challenge to the VB.Net Community at Large on OSSYesterday

I had a 3-4 way Twitter conversation with Roy Osherove today that left me hot under the collar even several hours later.  The conversation basically played out like this:

1. Roy:  Boo hoo, new .Net OSS projects are using advanced features in C# that might make those tools hard to use in VB.Net
   
2. Me:  Maybe, but I'm optimizing the user experience of these tools for C#.  I'm not going to sacrifice user experience in favor of a little extra reach.  Besides, VB.Net devs are a very small percentage of OSS users.
   
3. Roy:  Jeremy is an anti-VB bigot!  Who's with me VB guys?  VB guys can't use or participate in OSS because they're actively turned away by guys like Jeremy!
   

and then Roy proceeded to present himself as the champion of all those poor dispossessed VB.Net developers with some cheap theatrics.

 

To you Mr. VB.Net Dev:

Stand up if you don't like the way things are.  I have never once gotten any kind of specific suggestion about how to make StructureMap more palatable for VB.Net usage.  I've gotten complaints, and some questions (which I have answered), but not one single specific suggestion or patch that I recall.  Mr. VB.Net developer, if there's something you want or lack in an OSS framework that would make it easier/better to use that tool with idiomatic VB.Net, you know who's probably most qualified and able to write that patch?

AutoWiring in StructureMap 2.5+Yesterday

Getting the StructureMap docs a going.  Here’s an excerpt:

 

 

The best way to use an IoC container is to allow "Auto Wiring" to do most of the work for you.  IoC Containers like StructureMap are an infrastructure concern, and as such, should be isolated from as much of your code as possible.  Before examining Auto Wiring in depth, let's look at a common anti pattern of IoC usage:

IoC Container Anti-Pattern

One of the worst, but sadly  most common, usages of an IoC container is shown below:

        // This is the way to write a Constructor Function with an IoC tool

        // Let the IoC container "inject" services from outside, and keep

        // ShippingScreenPresenter ignorant of the IoC infrastructure

        public ShippingScreenPresenter(IShippingService service, IRepository repository)

        {

            _service = service;

            _repository = repository;

        }

 

        // FAIL!

        // This is the wrong way to use an IoC container.  Do NOT invoke the container from

        // the constructor function.  This tightly couples the ShippingScreenPresenter to

    �

It’s been years since I’ve gone on an Anti-Singleton rantJanuary 6

So apparently it’s time again:

See:

TDD Design Starter Kit - Static Methods and Singletons May Be Harmful

and

Chill out on the Singleton Fetish

 

TypeMock will make singletons and statics “testable” now, but you’ll still get screwed over with very tight coupling.