CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Karl Seguin

.NET From Ottawa, Ontario - http://twitter.com/karlseguin/

My .NET Wishlist

Following is a list of features that I wish were available to me as a .NET developer.

Distributed Caching
.NET's built-in caching capabilities, especially for ASP.NET developers, was a major new enhancement for web developers. When properly leveraged, both the output caching and programmatic caching API can lead to awesome performance. Unfortunately, as a system grows and performance really starts to matter, the built-in caching quickly falls apart - it doesn't scale whatsoever. .NET caching needs to be more pluggable and ship with a distributed caching system. I work with numerous load balanced solution and only rarely use the built-in caching mechanism because your caches will quickly fall out of synch.

Commercial Alternatives: Alachisoft NCache (not familiar with it, but lots of people talking about it)
Open Source Alternatives: memcached

For the curious, I've read that Facebook is using 200 memcached servers.

Less language features, more IDE features
I don't know what the story for Orcas is, but the tug-of-war between the IDE and the language teams has really sucked. Many things that should be IDE features are currently language features. Regardless of how you feel about background compilation, refactoring or edit-and-continue (I'm probably missing a couple), these things should be baked into the IDE with the language able to hook into it. Supposedly it's something being worked out so hopefully the story will get better soon.

Rethink the ASP.NET page model/life cycle
Thinking beyond the common request to implement an MVC pattern, I'd be great if the ASP.NET team could rethink the current model and life cycle. It leaks badly in any complicated scenario. 6 years after its release, I still don't fully understand it, and I'm ready to bet that I'm in the overwhelming majority. The only time it doesn't leak is when you don't need any of the fancy stuff it tries to do. I'm almost at the point where I just don't use .NET if I'm building a heavy web-based application. Forget learning an O/R mapper, test driven development or understanding domain driven development, the single best thing any ASP.NET developer can learn right now is MonoRail.

Silverlight Physics and Network API
I might be biased about this, but silverlight without a built-in physics engine and networking stack makes it useless in a lot of cases. It's a young product with a lot of growth potential, but it looks like the early versions will ship with some key features missing (I'm not just talking about the alphas...but the final 1.1 release).

Safe Thread-Local Storage
I know there's a lot of confusion about this, but I want an ASP.NET-agnostic method for storing data for a request. It isn't the end of the world, but code like the following, even if it's hidden away, bugs me:

SomeContext context = (HttpContext.Current == null) ? (SomeContext) Thread.GetData(Thread.GetNamedDataSlot(_dataSlotName)) :
                                                      (SomeContext)HttpContext.Current.Items[_dataSlotName];

Probably the reason I want this is because too many people (including myself) got burnt badly bythis.

Better handling of DBNull
It was hoped that nullable types were gonna make it easier to work with DBNull, but, to the best of my knowledge, that never worked out. There should just be something like the CSLA.NET's SafeDataHandler built into ADO.NET.

Better IDE Help
I find the built-in help horrible. Opening up firefox and googling something is _always_ faster and more accurate than hitting F1. It boggles the mind. In fairness, I've used a number of IDEs and in each case the help section is always the worst - VS.NET's is a lot better than most.

.NET on Linux As a first class citizen
Nothing more to say about this. .NET on Amazon’s EC2 would rock.
 



Comments

Ayende Rahien said:

> Safe Thread-Local Storage

Check this:

rhino-tools.svn.sourceforge.net/.../LocalData.cs

It handles this easily and I used it extensively.

# June 15, 2007 2:57 PM

Ayende Rahien said:

Rory Fitzpatrick,

You usually run MemCached on the web servers as well, it is a caching server, not a web server.

# June 15, 2007 2:59 PM

Tom Opgenorth said:

I'm curious about your request of .NET on Linux as a first class citizen.  Does not Mono do to trick?

# June 15, 2007 3:25 PM

karl said:

Rory:

lists.danga.com/.../004098.html

Tom:

Close, but not quite. All types of small issues, like occasional compatibility issues, performance, and overall uncertainty in the future of the product.

# June 15, 2007 4:15 PM

DevPrime said:

RE: TLS - this can be done with less code by creating threadstatic variables (pretty much the same thing behind the covers). But it sounds like what you really want is not a thread-specific storage mechanism, but a request-specific storage mechanism. The problem with TLS is that at the end of the request, the thread gets dumped back into the pool (with whatever was stuffed into it's slots), so you can't rely on it being clean next time you look at it.

RE: DB integration of Nullable<T> - we all complained about this right before the 2.0 release, but the problem is that the ADO.NET team didn't have time between the nullable CLR code wrap-up and ship date to integrate nullable types into ADO commands/readers/etc. Not so sure there's been much progress in that area though since a lot of effort got churned on LINQ instead.

# June 15, 2007 7:34 PM

cmyers said:

I've found that the most stable, safe TLS implementation I've seen on the .NET platform is the HttpContext.Current impl which happens to be based on the:

System.Runtime.Remoting.Messing.CallContext object which is the real gold of the operation.

The HttpContext.Current, object is stored in the CallContext.HostContext  (just call:  CallContext.HostContext as HttpContext and you've got it).

For storing TLS data that you don't want in the HttpContext.Current.Items dictionary, use CallContext.GetData and CallContext.SetData

There's your 'Everywhere' safe TLS.

# June 15, 2007 9:21 PM

Ken Egozi said:

As for "Learning MonoRail" - for those who find it awkward to learn Velocity or Brail (the default view scripting languages for MonoRail) there is also an option called AspView that adds c# to the mix, so you can MonoRail with c# only (with a not-too-bad intellisense experience).

I know, it is a kind of an advertisement, but what the heck. I believe it's could benefit many frustrated WebForms developers ...

www.kenegozi.com/.../aspview.aspx

# June 16, 2007 6:17 AM

Mike said:

Yes, I second the ASP.NET mvc (I heard Scott Guthrie was doing a prototype?) and the DBNull issue.

# June 18, 2007 7:27 AM

Rory Fitzpatrick said:

My bad, ignorance gets the best of me some times :D....plus I'd had a few...

# June 18, 2007 9:29 AM

Alex Davidson said:

At present, WeakDelegates are topping my wishlist. I know it's simple enough to hack up an implementation, but it's usually ugly when compared to the event/delegate syntax provided by the language, and requires the object exposing the event to be WeakDelegate-aware unless you want invocation lists containing 5000 dead stubs...

Better DBNull and ASP.NET MVC are quite high up my list, but my current project doesn't involve web or DB programming. :P

# June 18, 2007 11:22 AM

Rob Paveza said:

I think what we're seeing with LINQ (particularly LINQ-to-SQL) is a major step forward in IDE features.  However I am uncertain as to the utility of a feature such as it - maintainability becomes an issue when you use it.  That's kind of scary!

The ASP.NET Lifecycle: Honestly, this is really straightforward to figure out if you ever precompile an ASP.NET application using the web site publishing tool and then looking at the result assemblies at Reflector.  When you don't precompile, the ASP.NET compiler creates assemblies that incorporate your code and break any non runat="server" code into LiteralControls.  Your page is then constructed entirely in code (essentially) generated by ASP.NET.

Thread-Local storage can be accomplished by marking a static variable with the [ThreadStatic] attribute.  However, this doesn't work very well in ASP.NET because ASP.NET pools and reuses threads.  The real question to ask is: what design challenges are you facing if something like using HttpContext.Items vs. Thread.GetData is hindering your development?  Why can't you break that out into an encapsulated method or property somewhere?

DBNull is in fact addressed by the use of the "as" operator and nullable types.  Consider an "int NULL" column in SQL - using a DataReader you can query it as: int? val = dataReader["ParentID"] as int?;  The val variable will be null if the ParentID column is DBNull (the as operator returns null when type conversion fails but does not raise an InvalidCastException).

As I've told one of my co-workers trying to learn C#, the help system is your best friend, but you have to know what you're looking for.  It helps to have an idea of the class names that you're hunting down, and almost always I use the Index version of Help rather than the table of contents.  It helps me get details about properties, types, etc. fairly easily - even when just hitting F1 in code view.

I think .NET on Linux would be a great move.  Don't hold you breath, though.  :(

# January 16, 2008 11:08 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Check out Devlicio.us!

Our Sponsors