For a lot of developers, the Membership feature will be equivalent to using the Login controls and the public static Membership class. If you never have to deal with multiple providers, or provider-specific functionality, everything you need to use can be found on the Membership class. However, more complex sites will probably need to code against the MembershipProvider class, especially if they need to handle multiple providers.
Because the Membership feature deals with various aspects of a user, the MembershipUser class is available for carrying out user-oriented functions such as password management and user updates. As with the MembershipProvider class, you can also choose to implement a custom MembershipUser class. The usual coding approach is for custom provider implementers to optionally supply a custom MembershipUser class as well.
For custom provider implementers, it can be helpful to group the functionality of a MembershipProvider into different areas. Depending on how you plan to use a custom provider, you can choose to implement a very narrow set of functionality and eliminate the remainder of the provider implementation. For each of the functional areas, though, there are usually a few basic expectations that should be met for higher level applications and controls like the Login controls and the Web Administration Tool.
If you are thinking about integrating the Membership feature with custom providers for other ASP.NET application services, or with ...