Whidbey Design Flaws (Part 2)
Rob Howard writes responses to my criticism of the web Security namespace, noting that they had much of this discussion internally before deciding on the final outcome.
Still, I must take issue with him on a few points.
“> Why is GetNumberOfUsersOnline a method of the IMembershipProvider interface?
Because it's surfaced by the Membership provider - BTW, we're moving to abstract base classes in the beta (no more interface for any of the provider features) “ [1]
Then, why is it in MembershipProvider? Really... I don't see much value in this method, especially considering that it isn't even reliable anyway.
“With regard to AD we realized that AD doesn't support this, but we wanted to add AD support.” [1]
But, this isn't supported by AD, so it would take a modification of the AD schema to get it working, and even after that it wouldn't make sense to do this, because the web server would be the only place you could do this. It wouldn't work anywhere else, and since AD is usually used across the entire corp, not just some intranet app, it really doesn't make sense. I guess it makes a little more sense with ADAM as your user store, but most people aren't running ADAM currently (and then, you still have all the other LDAP based providers out there with the same issue).
“> why is there a GetPassword member
Ok, so what about the cases where the password is retrievable?” [1]
There isn't any rule that says an interface implementation cannot support more functionality than the interface it is implementing. As a general rule, however, passwords should not be retrievable. If someone wants to make their app insecure, make them do a little work (secure by default, right?).
“The obvious trade-offs here are complexitity vs. simplicity. I've personally maintained that the simpler and more understandable the software is the less bugs and support problems you will have and more people will use it because they can actually understand it! Furthermore, the pure object-oriented philosophy is somewhat elitist -- it places emphasis on who builds the software not on who uses the software, i.e. only the person who built it trully understands how it works due to the complexity. Our goal is to provide a model to address the problems of the majority - who will never extend our base functionality while still allowig the more advanced developers to extend our design, hence the 'provider design pattern'.“ [2]
I'm not advocating a million seperate interfaces being composed into one big object. However, there should at the very least be an interface that is common across all implementations. And by common, I mean an interface that is actually implemented across all valid implementations. If you can't depend on the contract, why have the interface in the first place? It is hard for me to understand how an interface that will randomly throw generic exceptions for methods it doesn't support (or return invalid values like the GetNumberOfUsersOnline method), makes the system any easier to use or accomplishes the goal you state. At least if there is a common interface, I know what features each implementation is going to provide and I can code against them. If you insist on violating such a simple principle, then you should at the very least provide for a way to query which parts of the contract that the interface supports within the contract and require a certain minimum subset of functionality. Then, I can do things like hide UI elements that line up to these properties/methods if I know they are going to fail if I call them, rather than putting up incorrect information on the screen or advertising features that aren't going to work anyway.
To me, it doesn't look like these are tradeoffs in terms of usability. They look far more like tradeoffs for features. I admit that it is cool to have support for secret questions and answers, number of users online, etc. all built-in. However, seeing that most implementations outside of the sql provider aren't going to support many of these members, it seems strange that the functionality of one provider dictates the architecture of the rest.