Marcus The Blog - Latest Comments

Re: Getting Started with MonoTouch

Pritsrk0786 — Mon, 07 May 2012 03:05:00 -0000

Hey I don't want to put my App to App Store just to deploy it to iPad for that i need to perches the $99 & register to iOS developer program

Re: Getting Started with MonoTouch

Sedot Sedot — Sun, 26 Feb 2012 11:26:09 -0000

About IoC for monotouch, take a look on https://github.com/gserjo/Tiko...

Re: Contextual Awareness – Making your container behave intelligently

mbratton — Thu, 07 Oct 2010 09:22:14 -0000

No... it's just another type of model binding at the simplest level.

Re: Contextual Awareness – Making your container behave intelligently

flipdoubt — Thu, 07 Oct 2010 02:05:28 -0000

Since Siege passes the services in to the action, doesn't this affect how you wire up your routes? Apparently not, because I can't find anything about routes in your post, but I am confused by why you do not have to reach into the container to pull out services to put into your routes. Am I way off base?

Re: Contextual Awareness – Making your container behave intelligently

mbratton — Sun, 19 Sep 2010 18:39:50 -0000

Mmm.... I dunno. Context, to me, is a very different thing than registrations. I'm not sure the way you're suggesting to do it would scale to cover the scenarios I'd want to cover ... but I'll take your word for it on this one :)

Thank you for showing me more about StructureMap, though.

Re: Contextual Awareness – Making your container behave intelligently

Robin Clowers — Sun, 19 Sep 2010 18:31:23 -0000

I see your point about the context being separate from other objects in the container, although I'm not sure how useful the distinction is.

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

var container = new Container(x =>

x.For<iaccountservice>().ConditionallyUse(c =>

{

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

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

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

}));

Then you have to register the user in the container:

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

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

container.Configure(c => c.For<systemstatus>().Use(new SystemStatus { IsOffline = true, MinutesUntilOnline = 5 ));</systemstatus></user></systemunavailableaccountservice></systemstatus></overdrawnaccountservice></user></wellfundedaccountservice></user></iaccountservice>

Re: Contextual Awareness – Making your container behave intelligently

mbratton — Fri, 17 Sep 2010 19:04:18 -0000

@bordev

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!

Re: Contextual Awareness – Making your container behave intelligently

bordev — Fri, 17 Sep 2010 18:46:55 -0000

mbratton> the fact that I would consider it as business logic is because you're throwing in environmental applicaton variables in the container's equasion which determine the plumbing during runtime.

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.

Re: Contextual Awareness – Making your container behave intelligently

mbratton — Fri, 17 Sep 2010 17:12:55 -0000

Hi bordev,

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.

Re: Contextual Awareness – Making your container behave intelligently

bordev — Fri, 17 Sep 2010 16:50:21 -0000

hi mbratton,

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.)

Re: Contextual Awareness – Making your container behave intelligently

mbratton — Fri, 17 Sep 2010 16:34:55 -0000

Hi Robin,

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<iaccountservice>.When<user>(user=> user.Account.Balance >= 0).Then<wellfundedaccountservice>())
.Register(Given<iaccountservice>.When<user>(user => user.Account.Balance < 0).Then<overdrawnaccountservice>())
.Register(Given<iaccountservice>.When<systemstatus>(status => status == status.IsOffline).Then<systemunavailableaccountservice()); "non-awareness"="" (or="" (well="" --="" 1:1="" :)="" a="" access="" accessor="" account="" account),="" account,="" accumulated="" achievable="" additionally,="" after="" again,="" all="" an="" and="" another="" application="" approach="" approach,="" as="" assume="" at="" available="" awareness="" based="" be="" been="" better="" blog-within-a-blog,="" but="" but,="" catch(exception)="" containers="" context="" could="" couple="" create,="" curious="" current="" decoupling.="" determined:="" different="" digress.="" do="" don't="" failure="" first="" for="" from="" funded="" get="" go?="" got="" great!="" guess="" has="" have="" here,="" how="" i="" i'd="" i'll="" i'm="" iaccountservice="" if="" if,="" in,="" information="" instance="" instead="" instead.="" interface-to-type="" internally="" is="" isoffline="true," it="" it.="" just="" know="" know.="" locator.addcontext(currentuser);="" locator.addcontext(new="" log="" long-winded.="" made="" many="" mechanism="" minutesuntilonline="5" now="" of="" on="" overdrawn).="" page="" passed="" point="" question="" register,="" registration.="" resets="" rules="" say="" separate="" show="" side="" some="" sorry="" sort="" structuremap="" structuremap's="" super-well.="" system="" systemstatus="" than="" that="" the="" there's="" think="" this="" throughout="" timer="" to="" try="" two="" types="" update="" use="" used="" user="" user.="" versus="" view="" want="" ways="" we="" well.="" wellfundedaccountservice="" were="" whatever="" with="" would="" you="" your="" {="" }="" });=""></systemunavailableaccountservice());></systemstatus></iaccountservice></overdrawnaccountservice></user></iaccountservice></wellfundedaccountservice></user></iaccountservice>

Re: Contextual Awareness – Making your container behave intelligently

Robin Clowers — Fri, 17 Sep 2010 14:08:07 -0000

Actually you can do conditional registration, although you would need to register your own object that accesses the model binder on each request get what siege is providing:

var container = new Container(x =>
x.For<iexampleservice>().ConditionallyUse(c =>
{
c.If(context => context.GetInstance<modelbinding>().For<selectiontype>() == SelectionType.OptionA).ThenIt.Is.Type<optionaservice>();
c.If(context => context.GetInstance<modelbinding>().For<selectiontype>() == SelectionType.OptionB).ThenIt.Is.Type<optionbservice>();
}));</optionbservice></selectiontype></modelbinding></optionaservice></selectiontype></modelbinding></iexampleservice>

Re: Contextual Awareness – Making your container behave intelligently

mbratton — Fri, 17 Sep 2010 12:15:47 -0000

Hi Confused,

I have to disagree. The Profiles feature in StructureMap, as I understand it (someone please correct me if I'm wrong!) works by you manually setting the profile mode on the container.

That means, as a result, you carry a reference to your container around, and have to explicitly say "Now run in this mode. Okay, good. Now run in this mode." You are basically back to telling the container what to do ... I don't think that's a smart container at all!

In this approach, the container figures those things out _on it's own_! You just teach it how to figure it out. That means no references to the container, and no explicitly telling it which "mode" to run in. It does it all on it's own!

Make sense?

Re: Dependency Injection into Controller Actions in ASP.NET MVC

mbratton — Fri, 17 Sep 2010 12:12:50 -0000

I forgot to mention -- I haven't explored any controllerless action ideas in much detail. I'm familiar with it, and off the top of my head I can see where to hook in to do it, but I'm concerned about it becoming even more scattered and hard to decipher (and test!)

If I wire everything into the container, then it becomes ServiceLocatorMVC :) What do you think?

Re: Dependency Injection into Controller Actions in ASP.NET MVC

mbratton — Fri, 17 Sep 2010 12:11:06 -0000

Hi Derick,

As with any piece of technology, it's available for abuse. The tool is only as efficient as the one yielding it. I'm not concerned on my team because we do actively review code and would catch things like this.

We have a bigger problem I think with controllers with 10+ injected dependencies. In the end, it's all down to judgement. I prefer to trust the judgement of the consumer and enable the functionality should they decide it's necessary, rather than take it away from them and say, "I know better than you about what you should be doing."

With regard to jumping back and forth between code and registrations to see what's going on -- I see your point. I think in the end its down to the team to build the expertise about the system and the business domain to understand things. To me its very similar to auto-wiring all your dependencies. By the time you get to your controller, you have no way of seeing which type is registered. You have to go look at the registrations to see what conventions are being applied, and infer the information.

To me, this is actually a little more straightforward ... at least we have some sort of code stating what the rule and how the decision was made! :)

So far we haven't run into an issue where people couldn't easily understand what was going on ... but like I said earlier, if it were overabused or implemented in a wacky fashion, I could see the potential for trouble.

Again, at some point I just have to trust to the judgement of the developer using the tool.

Re: Dependency Injection into Controller Actions in ASP.NET MVC

derick.bailey — Fri, 17 Sep 2010 10:04:41 -0000

interesting approach. i can see how the contextual resolution on the dependencies is a big benefit, here.

i have some questions and concerns, though...

are you worried about the overall design of the controllers when you have to start injecting dependencies into the individual action methods? it seems like a violation of a lot of the principles we espouse... encapsulation being the main one.

how does your team get a sense of the larger requirements when the logic of which implementation to use is baked into the IoC registration instead of the application itself? does this knowledge get lost? does it get confusing in to have to jump between the controller and the registration just to see if you need to look at the registration to understand what the possible implementations are?

have you explored any of the 'controllerless action' ideas? or has anyone really found a way to do that in asp.net mvc? I've been wanting to explore this idea for a while now. it seems that a class per action may be more appropriate in the cases where we find a controller becoming bloated. or perhaps, a Delegate per action, registered with a container...

Re: Contextual Awareness – Making your container behave intelligently

Confused — Fri, 17 Sep 2010 09:12:15 -0000

> Does that make sense/answer your question?

Yes. StructureMap does have a "profiles" feature, which I 'think' works in a similar fashion.

Thanks for clearing that up!

Re: Contextual Awareness – Making your container behave intelligently

mbratton — Fri, 17 Sep 2010 08:53:55 -0000

To clarify, in this example, if you user selects "Option A" in the drop down on the UI, the container sees that and knows to inject OptionAService into the controller action. If the user selects "Option B" in the drop down on the UI, the container sees that as well and knows to inject OptionBService into the controller action.

Does that make sense/answer your question?

Re: Contextual Awareness – Making your container behave intelligently

mbratton — Fri, 17 Sep 2010 08:49:18 -0000

Well, in my example there is an interface - IExampleService, and 2 implementations -- OptionAService and OptionBService. The container picks one of these implementations automatically based on user input and injects it for you..

Does StructureMap do that for you?

Re: Contextual Awareness – Making your container behave intelligently

Confused — Fri, 17 Sep 2010 08:35:41 -0000

I think I am missing something here. How is this different from what I currently do with StructureMap (aside from the fact that your example injected the service into the action):

public class SampleController : Controller
{
public SampleController(ExampleService service)
{
_service = service;
}
}

Re: Added support for Unity, Autofac to Siege.ServiceLocation

mbratton — Sun, 27 Dec 2009 16:24:56 -0000

Turned out not to be too hard. I went ahead and incorporated it. I posted details on it in my new blog post.

Re: Added support for Unity, Autofac to Siege.ServiceLocation

mbratton — Wed, 23 Dec 2009 14:40:29 -0000

It's certainly possible. It'll just require a custom implementation of IUseCase and some syntax to let people wire it up like that. When I'm putting together the extensions I'll take a peek to see how difficult that is and might just throw it in.

Re: Added support for Unity, Autofac to Siege.ServiceLocation

Adriano Machado — Wed, 23 Dec 2009 13:36:27 -0000

Great piece of code.

Is it possible to extend the container to give named instances when it is injected into a specific type? I know that Ninject is able, but is it easy to extend this functionality to Siege?

Thanks.

Re: The Siege Project: Siege.ServiceLocation, Part 2 – Contextual Registration and Resolution

mbratton — Wed, 09 Dec 2009 18:02:42 -0000

Interesting!

For #1 yes, context is tracked per user session. Turns out that what you're asking for on #2 is possible with this framework (I'll be covering areas like this in the next post, and I'll post a comment afterward explaining how it applies to your scenario).

Re: The Siege Project: Siege.ServiceLocation, Part 2 – Contextual Registration and Resolution

azaslow — Wed, 09 Dec 2009 17:40:52 -0000

For #1 I don't think that I expressed my question well. What you're saying is interesting, but not what I was thinking.

What I'm thinking about is something which addresses the need that I think the httpSessionStore is trying to achive (i.e. providing different context values depending on the active user or other varying context). I assume that your httpSessionStore returns different values based on the active session. What I was asking was for was actually using different context stores of the same type with the same container (or with multiple containers which use the same registration catalog).

The way that I implemented this is that I have a root container which has no context and where everything is registered. Later when a context is created a child container is created from the root container using the given context. This child container inherits the registrations from the root container. Once the child container is created its context cannot be changed (although I probably could allow changing the context with a little work).

For #2 I started to write a scenario and then I realized that what I'm asking goes beyond what you're trying to do. I think that what I'm looking for is simply to specify a factory to build the object and for the container (and context store) to be passed to the factory so that the factory can utilize the container to build the required object.

Thanks for your response. I think that what you're trying to do is something many people would like.