Marcus The Blog (by MarcusTheBold) - All Comments

re: A philosophical discussion about Inversion of Control frameworks

banq — Fri, 15 Jan 2010 03:38:48 GMT

> I want them decoupled completely

My IoC Framework is . include framework itself, please refer:https://jdon.dev.java.net/

this framework 's core is based in picocontainer 1.1, any components can be replaced by xml.

re: A philosophical discussion about Inversion of Control frameworks

mbratton — Mon, 11 Jan 2010 17:34:46 GMT

Man, I wish that's how it was where I work. I can't tell you the number of references to IKernel and IWindsorContainer that litter our codebase.

re: A philosophical discussion about Inversion of Control frameworks

Rinat Abdullin — Mon, 11 Jan 2010 17:14:25 GMT

I wonder, who cares about decoupling an IoC container from the rest of the code, when they touch only in config and host initialization sections anyway.

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

mbratton — Sun, 27 Dec 2009 21:24:56 GMT

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 19:40:29 GMT

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 18:36:27 GMT

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 23:02:42 GMT

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 22:40:52 GMT

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.

re: The Siege Project: Siege.ServiceLocation, Part 2 - Contextual Registration and Resolution

mbratton — Wed, 09 Dec 2009 19:24:22 GMT

@azaslow - #1 is something I've been thinking about for a while but wasn't sure I wanted to complicate things. I think my instinct right now is to leave it down to specific implementations of an IContextStore to determine how to manage it. But I'm not sure that's enough.

If I were to do a Per-Request, Per-Session, Per-Instance model, with three context stores (for example), would I predetermined a precedence for how I check? Would it be RequestContext before SessionContext before ApplicationContext? Would that force a user into a specific model (something I don't want to do).

Or could I allow users to add more than one context store? If I do that, do I need to allow users to specify a precedence between them? How do I make sure the correct store is looked at first for resolutions if multiple contexts are able to satisfy a use case, but they ultimately resolve to different types?

Those are the questions I've been debating. So in the end I've settled that until a better way is pointed out, I'll put the burden on the consumer to define an implementation of IContextStore that satisfies their needs. Maybe someone will create a ComplexContextStore that has an internal list of IContextStores for different scopes, and can it determine how to return its items in the correct fashion to the SiegeContainer. I dunno. I'm open to ideas.

For #2... I hadn't really considered that idea. Right now I suspect an object has to exist in context for it to be evaluated. I agree that it is more robust, but what I'm curious to see is a scenario where you'd do this. That will help me understand better what the goal is behind it. :)

re: The Siege Project: Siege.ServiceLocation, Part 2 - Contextual Registration and Resolution

azaslow — Wed, 09 Dec 2009 16:33:54 GMT

I am working on something similar to but not as elegant as what you're describing. I have two questions about what you're doing:

1) Is there a way to use different context store objects with a single container or is there a way to share registrations between containers?

I have found that it is very useful to be able to perform all of the registrations once and then use those common registrations under different contexts at the same time (in my case I create multiple containers each with its own context and each using a single shared registration).

For instance on a web server which is receiving multiple requests from different users you want to resolve using different contexts for each request but you don’t want to have to re-register everything for each request.

2) In the “When” part of the registration can only objects which are part of the context store be resolved or are the resolved objects registered with the container itself?

For instance, in your example where you are getting VendorStatus, must VendorStatus be an object in the context store or can it be any object which is retrieved from the container? I think that being able to make a decision based on an object in the container is more robust than limiting decisions to items in the context store alone.

re: The Siege Project: Siege.ServiceLocation, Part 2 - Contextual Registration and Resolution

mbratton — Wed, 09 Dec 2009 15:16:42 GMT

@Mihai: There were two reasons I didn't implement an AutofacAdapter or a UnityAdapter. First, I've never used them, so I'd have to learn them (not a big deal). Secondly, I felt that if this project had enough support from the community, and people wanted a Unity or Autofac adapter, one would be put together. Maybe I should put together a post on how to make an adapter?

re: The Siege Project: Siege.ServiceLocation, Part 2 - Contextual Registration and Resolution

Mihai — Wed, 09 Dec 2009 11:32:54 GMT

Looks pretty interesting. One argument I'd like to leave is that you should implement an adapter for UnityContainer.

The reason for a UnitContainerAdapter is simple, most firms have the firm belief that if it's from Microsoft than it is better than anything else. So as a developer you won't be able to propose the use of X or Y unless it's from Microsoft.

re: Introducing Siege

Grant Palin — Tue, 08 Dec 2009 22:06:36 GMT

Love the name, it is very fitting. I can relate to the feeling of being under siege by all the various tools that are available.

Sounds like the framework will be quite useful, if only to provide a little abstraction from the complexities of the tools.

re: Introducing Siege

John Sonmez — Tue, 08 Dec 2009 14:54:05 GMT

Looks like an interesting idea. I definitely agree with you about the high levels of complexity in configuration and consumption.

re: The Siege Project: Siege.ServiceLocation Part 1 - Introduction and General Use

mbratton — Tue, 08 Dec 2009 00:43:22 GMT

@Tariq: Yes, this will be open source, and people will be able to contribute. I am still thinking through how to set it up, but I don't think I want to make Siege.ServiceLocation a growing set of features, but might rather do a SiegeContrib for things like new IUseCase implementations, etc.

For something like an AutoFacAdapter, I think a seperate assembly that implements IServiceLocatorAdapter would be completely inline with what I've done with the other adapters (Ninject, StructureMap and Windsor).

People will definitely be encouraged to contribute.