2

Closed

Add a constructor in the controllers to receive a MembershipProvider / RoleProvider

description

If the controllers have an additional constructor to receive the membership provider or role provider instead of using always the singleton instance, the code will be much easier to test with TDD (The membership provider can be mocked).
 
For example,
 
private MembershipProvider _provider;
 
BaseFormsAuthenticationController ()
{
_provider = dotNetMembership.Provider;
}
 
BaseFormsAuthenticationController(MembershipProvider provider)
{
_provider = provider;
}
 
Thanks
Pablo.
Closed Aug 7, 2009 at 2:36 PM by TroyGoode
The controllers now use "poor man's DI" to allow the provider to be injected.

comments

TroyGoode wrote Jun 7, 2008 at 11:07 PM

Cibrax, I agree completely and have done just this on a project I am employing TDD with at work. I'll slot this for the TDD release (2.5).

wrote Jun 7, 2008 at 11:07 PM

wrote Jun 7, 2008 at 11:07 PM

cpeterson wrote Jun 13, 2008 at 7:16 AM

I like this idea but I think using injection would be a better.

TroyGoode wrote Jun 13, 2008 at 1:14 PM

@cpeterson: With the constructor overload taking the MembershipProvider as an argument, that allows for injection by all DI frameworks that I know of without tieing it to any one of them (something I want to avoid).

wrote Feb 7, 2009 at 6:33 PM

wrote Aug 7, 2009 at 2:36 PM

wrote Aug 18, 2009 at 3:04 AM

wrote Feb 14, 2013 at 7:12 PM

wrote May 16, 2013 at 9:02 AM