I've done quite a bit with Whidbey and .Net 2.0 since Beta 1 hit in mid-2004. I was one of the early adopters that submitted bug reports as well, and I've tech editted several .Net 2.0 books, and I'm mostly impressed with .Net 2.0, but there are some aspects that I'm dissapointed with (you can read past ones on my blog).
I've been wrapping some of my existing code with the built-in providers in ASP.NET. I'm finished with the MembershipProvider, but all I needed was 4 of the methods, and the abstract class has over 20. What a waste. I'm in the process of wrapping my code with the SiteMapProvider, and that one looks more civilized.
Microsoft has touted it's Provider pattern as a way to configure application behavior. They've touted it as a custom mix of
Strategy and
Plugin. It's true that you can change the configuration file, and you'll hook up a different provider, and the behavior of the application will change.
What's not widely known is that _every_ provider is a
Singleton. There is no getting around it. The biggest implication of this is that where before, only few had to worry about writing thread-safe code, now even the hobbyist has to be aware of threads when creating a provider. There is not a way to configure them away from being singletons, either.
Using them with ASP.NET is the biggest concern because every request runs on a different thread. Handlers are per-thread, but IHttpModule(s) have AppDomain scope just like providers. What this means is that providers are not pluggable components. . . they are services and must be treated as such. They are entities that will serve multiple customers. Each customer doesn't get his own instance of the provider, but one instance is shared for the life of the application. I'd prefer to have one instance per use.
Early on in the Beta cycle,
Rob Howard had the same thoughts as me:
"This is a disastor waiting to happen. We you have an API that is
funtionally wrapped up into a package a static methods (I know the Role
Provider class isn't static, but it's access is) you have a service. . . " 4/16/2004
You can verify my facts here by reading
this article on MSDN (search for "thread").