views:

211

answers:

2

We're going to be using a custom role provider with WCF. The overridden method GetRolesForUser will require the use of an already existing RoleRepository.

Now, with a run-of-the-mill class, we'd construct it using StructureMap and the RoleRepository dependency would be injected via the constructor.

However, it's WCF that does the constructing of the the custom role provider class and that's 'done' declaritavely via the roleManager attribute in the web.config.

I don't really want to hard-wire the RoleRepository depndency into the custom role probvider class but it's looking like I'll have to.

Any ideas?

A: 

The RoleProvider and related types are legacies of ASP.NET which are infamous for not being DI-friendly. They require a default constructor and there are no hooks offered to initialize them. It sucks, but that's the way it is.

In such situations, the best remedy is to implement the RoleProvider as a Humble Object. In other words, the RoleProvider must wire up all dependencies, but from there, it delegates all implementation to your own open and extensible API.

Mark Seemann
Yup, excellent idea.
A: 

I'm having the same issue in MVC land. Both the RoleProvider and MembershipProvider classes simply aren't designed for dependency injection or test driven development. I abandoned all attempts at creating a custom MembershipProvider because of its need for hard coded configuration ties when instantiating a MembershipUser. Wasn't worth it and the interface isn't all that great anyway.

I think you're right, Mark. Looks like the only way to go. Still makes me feel a little dirty though. I'm gonna have to take a shower after coding that up. LOL. :-)

I LOVE the MVC framework and I look forward to a day when other MS products are as simple and powerful. MS can't get credit for the design, but I still give them credit for doing it right. :-)

Jason Stonebraker