views:

294

answers:

1

Been lurking for a few months and decided to jump in with a question. I am very new to Windsor and IoC in general. I can get Windsor to work with my MVC2 project with no problem. The project I am working on is a "portal" of multiple applications under one MVC2 project using the new Areas concept. In this scenario, each Area will actually be a separate application inside the "portal". We are doing this to effectively share a LOT of common code, views, authentication, and cross-application functionality. Many of our apps link to one another, so it made sense after discussing it to combine them into one project.

What I am wondering how to do is actually allow different Areas to inject different concrete classes? In my limited understanding, the Application_Start is governing building the container and assigning it as the controller factory. I don't necessarily want to do all the injection at the application level. We have a config system where we have a config.xml at the root of every Area and those settings override any root settings. I would like to continue that trend by having the injections for each Area be read by the Area's config.xml (an inheritance similar to Webforms web.config where the config in a lower folder overrides settings in a parent folder).

Example: I would have an ILogHandler which would need a different concrete implementation depending on which Area of the application I am in. So I would need to inject something different depending on where I am at in the application.

I can easily do this using factories since each area could have it's own set of factories, but I am attempting to take this opportunity to learn about IoC and what the benefits/drawbacks are. Any help would be appreciated.

A: 

Just FYI - you absolutely must not have area-specific security code. For example, a factory or invoker which injects [Authorize] attributes depending on the current area could open your application to attack.

Contrast this with a MyAreaBaseController, which all controllers in your area must subclass. [Authorize] attributes (and other security-related code) here are OK since they're applied to the type and are independent of any concept of "area".

Levi
Agreed. All of our security code is and always will be common in the root areas. We do have base controllers, but none of what I'm talking about concerns security. We've actually written our own attributes that are system-wide to handle security and will have nothing to do with the IoC container. My question is around domain-level objects like events, logging, etc. Thanks for the tip!
Doug Shontz