One of the nice things added in .NET 3.5 is the ability to use the ASP.NET membership providers from Windows form and WPF applications, also known as Client Application Services. It's a great concept that I'm looking at for a project I'm working on.
One key piece of implementing authentication is the ClientFormsAuthenticationMembershipProvider class (yea, it's a mouthful) which provides the client side membership provider function and is a subclass of MembershipProvider. So far, so good.
Check out this screen shot from the members for the ClientFormsAuthenticationMembershipProvider class:
Notice anything interesting? Like almost all of the properties say they're not used in this class? If you look at the methods, you'll see pretty much the same thing.
This is terrible object oriented design. This class inherits from a class when it only implements a very small subset of the methods and properties of the base class. This class design makes me think there are at least two separate coherent classes at play here (one for "client-side membership providers" and one for "server-side membership providers") which should be separate classes composed into a "membership provider". Or they could have created a parent class of the existing MembershipProvider with the appropriate properties and methods for a "client-side membership provider". Or what's more likely is that there are several coherent classes hidden here, but frankly I don't want to think about it any more.
I appreciate the fact that they've added the great ability to use the MembershipProvider from Windows form applications. I just wish they would have done it in a way that doesn't turn my stomach.
1 comments: (+add yours?)
I'm laughing inside while imagining your discomfort. he he he.
Post a Comment