The Price of .Net's Diversity

.Net, since its' inception, has always tried to be a friend to everyone. A truly general purpose set of software development technologies. It offer both RAD and enterprise level development tools, dynamic languages, functional languages, type-safe languages, and OOP languages. With the Entity framework, Astoria, the DLR, dynamic data, and more shortly on the way the incredible breadth of the .Net offerings just continues to expand - and that's without even mentioning any of the open source technologies.

But whilst with this incredible diversity we gain a lot of flexibility we have to pay a heavy price. Perhaps the biggest cost is the discipline we must exercise when we approach problems. .Net makes it very easy, and even seem rewarding, to do things badly.

Whilst something like Ruby on Rails makes it difficult to work following patterns and practices which are not standard in its community. .Net at best does little to encourage what are generally considered good practices (separation of concerns, low coupling, explicit intent, unit testing, etc...), and at worst encourages bad practice.

Take the provider mechanism introduced in ASP.NET 2.0. Yes this makes it quick to bind a data grid to a data source, but the moment that you need to do something beyond a demo app it start to lose its shine and make life difficult. Unfortunately a lot of developers struggle on anyway and concerns that ought to belong to a data or repository layer are placed in the markup of an aspx page. Yes there is an object provider, and as CLSA.NET does, this can be usefully put to work.

Another example is the dataset, invidious things that seem to be an overt attempt to subvert OOP, AOP, or any other good practices.

I could list many more examples. Often these things are a fools gold that promise much but deliver nothing. They lead to more code being written. They make unit testing at best very difficult, and often impossible. They inhibit changes in functionality. They make maintenance and code handovers very taxing.

But what concerns me almost more is that they seem to breed 'wrong thinking' and the proliferation of anti-patterns and code smells. They become a bad influence under whose spells developers, and perhaps even more teams, can fall and remain trapped.

I like the flexibility, and the diversity I get being a .NET developer. I would just like MS to adopt a stronger lead in making it easier for me, and others, to follow good practices. Happily there does seem to be some sight of some cavalry coming over the hill. In the web world the new ASP.NET MVC framework could go a long way to meet this critique, and perhaps Prism in the WPF world.