0

The ASP.NET Provider Model was a great technology to solve the problem of allowing someone to "plug in" a separate implementation of some functionality into a web application. The Provider Model is generally a bit painful to implement requiring configuration so it's used minimally.

IOC is a great way to ensure separation of concerns at each level of an application, so it is good to use extensively to support Unit Testing of all components.

If a web application is using an IOC container, it seems wrong to use the Provider Model also, because you seem to be abstracting out something that is already abstracted out, creating two levels of complexity (except possibly for existing providers - I am talking about making custom providers).

(see more on this on my blog post: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html)

I am using AutoFac for IOC and it's possible to allow "configuration override" so that seems like a good alternative to meet the same solution the Provider Model gives me, however I don't know a whole lot about how MEF might meet this requirement or if there is something else out there I am missing?

If you could design an ASP.NET MVC web application from scratch, and a requirement was that you had to on-sell a packaged version so others could "plug-in" certain bits of data access without needing to re-compile, how would you go about implementing it?

nootn
  • 851
  • 1
  • 12
  • 16

2 Answers2

1

I think this depends on what the pluggable component is.

Some things have to be providers. For example, if you're using features from the standard ASP.NET membership provider, you have to derive your functionality from that. In those situations, I've found it is easy enough to write a sort of "proxy" provider that does dependency resolution and passes along the call to the implementation registered with DI.

For example, assuming you've got Autofac wired up to MVC DependencyResolver, you might see something like this in your membership provider:

public override bool ChangePassword(
  string username,
  string oldPassword,
  string newPassword)
{
  var provider = DependencyResolver.Current.GetService<IMembershipService>();
  return provider.ChangePassword(username, oldPassword, newPassword);
}

I haven't found any automatic functionality that lets you decouple the built-in providers.

For the things that aren't providers, just use the IoC functionality as usual. I prefer config-less IoC using Autofac's assembly scanning functionality and modules, which would allow you to basically drop an assembly with your overrides into the bin folder and restart the app. Scan for any modules at startup and register them. If you want to be more explicit than that, you could create your own startup interface like...

public interface IMyStartup
{
  void Start(ContainerBuilder builder);
}

...and then scan for just your specific interface and call the start method on that. There are a ton of ways to do it (attributes, types, assemblies in a specific known location, etc.) but it all boils down to assembly scanning.

Travis Illig
  • 23,195
  • 2
  • 62
  • 85
  • Thanks mate, I think assembly scanning with AutoFac looks like the best way to go! I can't vote up right now because I don't have enough rep but when I get enough I will come back and do it! – nootn Dec 17 '11 at 12:56
  • You may not be able to upvote, but you should be able to accept the answer - no rep required. Please do if you feel this was the right answer. – Travis Illig Jan 03 '12 at 18:04
  • I now have enough points - I have upvoted and marked as answer, sorry for the delay. – nootn Mar 25 '13 at 12:02
0

Unity and structure map also.provide assembly scanning. Unity requires an auto.registration module to do this.

brumScouse
  • 3,166
  • 1
  • 24
  • 38