Thank you for showing me more about StructureMap, though.

The implementation of your second example looks pretty much the same:

var container = new Container(x =>

x.For().ConditionallyUse(c =>

{

c.If(context => context.GetInstance().Account.Balance >= 0).ThenIt.Is.Type();

c.If(context => context.GetInstance().Account.Balance < 0).ThenIt.Is.Type();

c.If(context => context.GetInstance().IsOffline).ThenIt.Is.Type();

}));

Then you have to register the user in the container:

container.Configure(c => c.For().Use(currentUser));

Likewise in the catch method, you register the system status:

container.Configure(c => c.For().Use(new SystemStatus { IsOffline = true, MinutesUntilOnline = 5 ));

Well, upon reflection there are cases where it could be business-y logic. Maybe I want to pick implementations based on some business rule.

But… in the end I still think of that sort of thing as noise. Anytime I have to deal with picking an implementation, it’s noise to me. Doesn’t matter if business rules are driving it.

Siege has a construct where you can bundle things like this together. We bundle similar registrations together as cohesive units for a variety of reasons… portability of registrations across apps, for example. Another reason may be to encapsulate that sort of business logic together. The construct is called Using.Convention.

I still think that decisions about which type to create belong in the container. I get the concern about the rules … and honestly I could probably split those out into encapsulated objects that could be given to the container versus constructed directly into it.

I’m going to think about that one … I think maybe there is a case for both usages. Thanks for the food for thought!

IMO application plumbing needs only be done at design time and scattered business logic avoided so I’m not really convinced.

though it’s an interesting thin line where responsibilities of container starts/ends.

I don’t really consider that to be implementation selection to be controller logic or business logic. I consider it to be #1 responsibility of the container. At the end of the day all that container setup says is this:

When I select Vendor X on this page, I want to get an instance of VendorXService so that when I call a method (say, service.Submit()) it sends the info to the correct vendor.

I don’t see anything inherently wrong with moving those sorts of decisions out of your controller and into your container. It’s application plumbing moreso than anything.

What I’m wondering is what is the real advantage of moving typical controller logic – choosing the right implementation based on some UI selection – to the container in the registry section and make it smart?

This leakage of controller logic into the container clouds the distinct create/destroy concerns of the container and I wonder if this is a good thing regarding maintainability of your UI and controllers in this example?

Losing the service locator tp make stuff less ugly is one thing but I think it might be better to leave the implementation selection in the controller. (Then inject a typed-factory using the windsor to lose the service locator.)

I would say “not exactly”. The core distinction between how I’m doing this and how StructureMap is doing this is that I would say my stuff is more adaptive.

Awareness is just one way the container is able to understand what you want to do. My goal is to decouple what can be considered context and where it comes from away from making the container the end-all, be-all for determining what context “is”.

For Siege, context can be … anything. It can be information about the current user. It could be the time of day. It could be some action the user just initiated. It could be problems with an integration point. Literally, anything.

The container is designed to be able to either collect these as you go, to be made aware (or, in the near future, to automatically “become” aware on its own).

This could easily be ignorance on my part, but in the scenario you posted, it seems like these concepts must exist within the StructureMap container already for you to be able to use it? That is to say, you have to be able to resolve a “dependency”, which really isn’t a dependency, and likely not anything you even want inject/resolve anywhere. Is that correct?

I did a quick spot check on the googles for StructureMap, ConditionallyUse and IContext. Nothing really stood out to me that defined it well enough for me to get a good grasp of how it works.

Really, for me, it comes down to divorcing the concept of context and where it comes from away from types that can be injected. The container absolutely should be aware of context. But I don’t want to make users register the ModelBinding class unless they actually plan to make it a dependency of some type, or resolve it for their application need.

I’d much rather give the container pieces of information as I go, or give the ability to find information on its own as it goes. Creating an object just so that I can register it, just so the container can look it up as a rule… seems kinda like a workaround, to me. In fact, I could do the same exact thing with Siege during registration. But that doesn’t really do what I was trying to do.

I guess ultimately what I’m saying is … how would you express something like this?

Let’s assume the following types:

interface IAccountService
class WellFundedAccountService
class OverdrawnAccountService
class SystemUnavailableAccountService

I’m a customer of a bank. When I log in to their website, the system requests an IAccountService implementation. Based on whether or not the current customer’s account is overdrawn or not, I want to either get WellFundedAccountService or an OverdrawnAccountService. Additionally, if the last request to get a user’s account (same or different user session) failed, I want to show a SystemUnavailableAccountService (I want this rule to be true for 5 minutes, and we’ll ignore any concurrency issues).

I know it’s a contrived scenario, and disconnected from the original example in this post, but I think it demonstrates the difference. These things are purely derived from arbitrary information. I could make the example completely more arbitrary than this. These are the sorts of things I want to be able to support.

Again, it may be my ignorance in this matter, but it doesn’t seem like StructureMap natively supports this level of complete arbitrariness.

For completeness sake, here’s how we would do it in Siege:

locator
.Register(Given.When(user=> user.Account.Balance >= 0).Then())
.Register(Given.When(user => user.Account.Balance < 0).Then())
.Register(Given.When(status => status == status.IsOffline).Then

From here, there’s a couple of ways to do it. I’ll approach this with “non-awareness” to show another side of it.

On log in, after current user has been determined:

locator.AddContext(currentUser);

Now all the information is available for the first two rules (well funded versus overdrawn). Additionally, we could have made the rules based on Account instead of user and passed that as context instead. But, I digress.

On your account accessor page (or whatever mechanism used to view your account), assume you got a system failure of some sort for a different user.

try
{
//access your account, assume at this point IAccountService is a WellFundedAccountService
}
catch(Exception)
{
locator.AddContext(new SystemStatus { IsOffline = true, MinutesUntilOnline = 5 });
//assume internally that after the timer it resets to IsOffline = false
}

Again, I would say that this is all achievable with Awareness as well. But I want to show how context is accumulated throughout an application separate from the point of registration. The question I think is — if you were to use StructureMap’s approach, how many types would you have to create, and register, and get instance to and update as you go?

I’d be curious to know. I don’t know StructureMap super-well. And if, great! I think this is a better use of containers than a 1:1 interface-to-type decoupling.

Sorry for the blog-within-a-blog, I guess I’m just long-winded.

var container = new Container(x =>
x.For().ConditionallyUse(c =>
{
c.If(context => context.GetInstance().For
() == SelectionType.OptionA).ThenIt.Is.Type
();
c.If(context => context.GetInstance().For
() == SelectionType.OptionB).ThenIt.Is.Type
();
}));