Whidbey Goes To Far?

Why is it that Microsoft can't seem to call users “users” and groups “groups?” Role based security is great and all, but how many people outside of the framework team actually call groups “roles?” I guess User wasn't short enough either, because someone thought it had to be called a “MembershipUser” instead.

Why is GetNumberOfUsersOnline a method of the IMembershipProvider interface? After all there is no way to accurately determine this if you are using the SQL provider (yes, they do have a “workaround” for the obvious problem, but the number definately is not going to be accurate, and the IsUserOnline method can't be trusted to return valid answers either). However, if that wasn't enough, the fact that the AD implementation must always return 0 should have been another clue.

Is the person who came up with that bright idea the same one who decided that the interface should support secret questions and answers? Again, the AD provider doesn't support this either, but just throws a generic HttpException containing the text “API not supported”.

On the same note, why is there a GetPassword member, which also cannot be supported (and for a good reason) by most directory services (including AD).

How is a generic exception containing the text “API not supported“ any better than a “Method not found“ exception thrown by the framework? Why do we have interfaces in the first place if we aren't going to require that classes implement their contracts?

So, we have crappily named interfaces full of members that can never be implemented under many circumstances. Maybe they should have just made them an application block instead so that we could ignore them.

6 Comments

  • They all sound like excellent points....I guess it _IS_ pre-beta code. I hope the people who own these namespaces are reading.

  • Role based security is great and all, but how many people outside of the framework team actually call groups “roles?” ?



    I do. And the better answer is, it depends. If you want to group certain users together with no other intent than to be able to reference the group instead of the individual user. On the other hand, if you want to group a certain set of users according to the role they play or the permissions they have (= the actions they can perform on certain resources), then role is much more suitable as a term.



    From an API POV I think you are right though. Keeping it simple will get us a long way.

  • Maybe they called it MembershipUser so it wouldn't clash with the already defined User object if you were using pre 2.0 code.

  • Roles are a well established term. A role is a flexible grouping mechanism that is defined per application or even per function. A group is managed per machine, domain or even across an entire enterprise.

  • Agreed.



    I always assumed that the whole Membership part is "too little and too much". I love it that MS puts it out, but - well - it is a litle too "non oo".



    For your interface:



    Would have been etter to spltit the interfaces. Something like ILoggedInUserTracking, and if I dont support it, then I dont implement it :-)

  • Here's some answers for you straight from the source ;)



    We called the features 'Roles' since the feature it augments is called role based security. The MembershipUser object has its name -- as someone else correctly noted -- so it wouldn't collide with the already existing 'User' class.



    > 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)





    > that the interface should support secret questions and answers

    Yes and no. With regard to AD we realized that AD doesn't support this, but we wanted to add AD support.



    > why is there a GetPassword member

    Ok, so what about the cases where the password is retrievable?



    I think the critisim is interesting, but a bit elitest. There is always a trade-off between design and functionality. While purer oo design is more palatable to some, functionality is often times more important. Our goal is to provide a model to address the problems of the majority, while still allowing the more advanced developers to extend our design.

Comments have been disabled for this content.