Currently I'm developing a project that basically is built with ASP.NET Web API. The membership system I'm using is ASP.NET Identity. The only problem I'm seeing with this is that the membership system is being highly coupled with the API I'm bulding.

In that case I've thought on bulding interfaces to expose the membership system functionalities the app needs and then use dependency injection to inject the current Identity system.

The only thing is that on all the time I've been looking on the internet about authentication and authorization in ASP.NET I've never seem this done. So I've started to wonder whether this is or not a good practice.

Is this a good practice or no? If not, why?

  • The membership system is in it self decoupled...what makes you think otherwise? – deostroll Apr 27 '14 at 3:08
  • Well, I thought on the same lines of data and entity framework. Althought I'm using EF, I know that there is NHibernate, and also other ways to persist data like NoSQL. So, I abstract this with repositories so that if I need to change the specific EF for some other thing it is easy. I thought the same should be done with membership systems. – user1620696 Apr 27 '14 at 3:18

Asp.net membership provider is decoupled in itself. In fact it is an implementation of MembershipProvider base class. SqlMembershipProvider is a concrete implementation of the former.

Is decoupling membership a good practice? -> Yes.

Decoupling is generally good for making the functionality reusable for diverse clients. Tomorrow if some android clients want to make use of the authentication module it can, provided it is exposed over http via wcf or web api. Writing software for wcf/webapi forces us to make our logic a decoupled and independent on it own to some debatable degree.

But a more important question is, is it practical? Can you implement this in the software you are trying to create? That is a call one should take after accessing how quickly you want to deliver the software. So once you start thinking on these lines, though the prospect of your code being used up by clients in other technology might seem cool, its actually bad for the budget or delivery concerns. Hence you might not go for decoupling to such degree.

But if you are using the framework provided feature, the mechanism is already decoupled for you. It obviously states this is a good practice. In other words, one can argue its already there because it is a good practice.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.