How do I architecture and implement custom membership provider?

I am trying to learn ASP.NET MVC. After reading through many articles on the web, I have put together a crude sample application that authenticates against an existing SQL database using custom membership provider.

My models class library project is structured as shown below.

• Sigma.Models
  • Implementations
    • FormsAuthenticationService.cs
    • MembershipService.cs
  • Interfaces
    • IFormsAuthenticationService.cs
    • IMembershipRepository.cs
    • IMembershipService.cs
  • Providers
    • SigmaMembersipProvider.cs
  • Repository
    • SqlMembershipRepository.cs
  • MembershipModel.cs

My questions are as follows:

• Should I have to create another class library project like Sigma.DataAccess to keep the providers and repositories separately? Is this an acceptable way to do MVC solution architecture? This is only a proof of concept that I am working on and the actual project can get really huge. I want to make sure that I don't do anything stupid to begin with.

• IMembershipRepository and IMembershipService contain mostly the same functionalities except that IMembershipRepository returns data using the custom deve开发者_JAVA百科loped MembershipModel object; whereas IMembershipService is an interface of the standard ASP.NET MembershipProvider and returns MembershipUser and MembershipCollection. Should I have the interface IMembershipRepository inherit from IMembershipService?

• I would like to have models project reusable so I can use it against any other UI applications like WebForms or WinForms. Is that possible with the way project is structured?

• Also, I don't want to use the ASP.NET out-of-the-box membership provider because I need a solution that can work against an existing database. I assume that would mean I have to customize the features available in the ASP.NET membership provider to work against my custom database. Please correct me if my assumption is incorrect.

Thanks in advance.

---

Should I have to create another class library project like Sigma.DataAccess to keep the providers and repositories separately? Is this an acceptable way to do MVC solution architecture? This is only a proof of concept that I am working on and the actual project can get really huge. I want to make sure that I don't do anything stupid to begin with.

Yes - keep them separate in case your implementation changes you have less impact.

IMembershipRepository and IMembershipService contain mostly the same functionalities except that IMembershipRepository returns data using the custom developed MembershipModel object; whereas IMembershipService is an interface of the standard ASP.NET MembershipProvider and returns MembershipUser and MembershipCollection. Should I have the interface IMembershipRepository inherit from IMembershipService?

Actually in the samples provided - there actually seems to be no difference in the implementation - both methods are bool ValidateUser() which is definitely a repeat but because they each have an end use that could 'potentially' change they are abstracted into two separate interfaces, so I would not have one inherit from the other.

I would like to have models project reusable so I can use it against any other UI applications like WebForms or WinForms. Is that possible with the way project is structured?

Yes - but I would break out and keep only the models in that project. Anything that is not a model - should not be in that project.

Also, I don't want to use the ASP.NET out-of-the-box membership provider because I need a solution that can work against an existing database. I assume that would mean I have to customize the features available in the ASP.NET membership provider to work against my custom database. Please correct me if my assumption is incorrect.

That is correct - you need a custom SQL membership provider