Autofac 1.1 & Autofac.Extras

[Nicholas Blumhardt]

Hi Everyone,

I've been thinking lately about structuring the 1.1 release as
Autofac.dll (the core) plus a set of additional assemblies
implementing Autofac.Extras namespaces.

The purpose of this would be to keep the 'kitchen sink' out of Autofac
core - the initial candidates I'm considering for Extras would be:

* Tagged (named) contexts
* Automatically-generated factory delegates

The big downside of this is the proliferation of assemblies and the
additional complexity faced by new users.

Some feedback on this idea would be great.

Nick

[Gilles Bayon]

Why not merge the InstanceScope notion in the tag context, this will
more consistant ?
In all case we are speaking of scope with two manner to do the thing.

There could be some defaults TagContext already there when building a
container, the "SingletonScope", "ContainerScope", "NoScope"
The InstanceScope.Factory must be an 'alias' to the "NoScope"
tagcontext.

Cheers,
Gilles

[Rinat Abdullin]

Gilles,

We'll see what Nick says about that, but I myself just do not feel
that this merging is the good thing to do.

Scopes are core functionality of autofac (one cannot live without
them), yet named tags are not. They are just an optional extension.

[Nicholas Blumhardt]

Hi,

Gilles, thanks for posting. I had to think about your suggestion for a
while - any simplifications we can make are high on the priority list.

I do think that tags are a separate concern from scope, but the line
is blurry:

* A tag identifies a layer in the hierarchy of containers - e.g.
Application/Session/Request/Transaction or something along those lines
depending upon the architecture. A tagged component will share the
lifetime of the layer it is created in, e.g. an ISession that is
registered with the Session tag will live as long as the Session-
tagged container, regardless of whether it is the only instance or one
among many.

* The scope of a component determines the sharing of instances within
the subtree in which the component is visible. If a component is
factory scoped, then all requesters will get a new instance, if it is
container scoped then each subtree will have its own instance, if it
is singleton scoped.. well, that probably doesn't make much sense -
I'd better write that unit test..!

I am starting to feel that tags are a crucial part of Autofac - I
actually just had a horrible night because I woke up at 3am with an
idea of how to better implement them buzzing around in my head :)

There is a new release available from the downloads section in which
you can try the latest version out. Tags are in the Autofac assembly,
you need to import the Tags namespace to get the extensions. It would
be great to get some feedback on the way tags are implemented now, and
also to get some suggestions on how to describe them clearly.

Please keep the ideas coming! I'll think some more about your
suggestion and see if there is a way to make the two features work
together more cohesively.

Cheers,

Nick

[Rinat Abdullin]

Hi Everyone,

I've just figured out one justification for my unreasonable urge to
avoid tagged contexts.

My shared modules are equally used on the side of the web interface,
desktop interface and the automation engines without any module
switches (i.e. "RegistrationMode.Web"). Obviously every application
type has its own structure for the container hierarchy:
1. Web: application-wide scope with child scopes per session
2. Engine: application-wide scope with dedicated scope per each task
execution (just to keep the environment clean)
3. Desktop: application-wide scope with a child scope for the current
logon/configuration. Then every view gets its own scope (optionally
view execution context gets one more to resolve commands). Plus
workspaces can declare their own scopes with overrides to display
views in some unusual manner.

The points I'm getting to, are:
1 Tagged scopes would complicate module re-usability in this scenario;
2. autofac IoC magic is wonderful. Shared components just get wired up
and run properly in every scenario (and there are different configs -
singletons, stateless micro-components with container scopes or
stateful commands that require factory, etc with different complex
relations between these). And I know for sure that the unneeded ones
will just stay inactive.

Best regards,
Rinat Abdullin

On 26 фев, 02:40, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

[Nicholas Blumhardt]

That's a really good point. Fantastic blog article too, I need some
more time to properly digest it (there aren't enough hours in the
day!)

The way Autofac handles context/scope is definitely one of the things
that will be most unusual to people familiar with other containers.
Getting some guidance on all of this will be invaluable and I think
this discussion is a great start. Inevitably people are going to be
looking for "I use X in container Y, how do I do that in Autofac?"
kind of guidance, and I'm not sure we're in a position yet to really
clearly describe best practices.

I can see how tagging scopes could become a big problem for
flexibility. I'm still really keen on simple two-level or anonymous-
scoped designs, but I can see scenarios where it will be really good
to pin the lifecycle of a component to a particular level in the
hierarchy. For now perhaps using tags should be the exception rather
than the rule.

Really interested to hear more of your ideas on this - there is no
hurry to set 1.1 in stone so perhaps we can investigate some different
models along the lines of what you're doing by hand? (I remember a
post quite a while ago that got the whole tags thing kicked off...)

Nick

[Rinat Abdullin]

Nick,

1. Yeah, that default setting of 24h in one day used to embarrass me,
too))

2. Scopes/contexts is not the new concept. Object Builder used to have
them in form of WorkItems. But the whole idea got killed by the
unusable and invasive implementation. However, the folks at Redmond
had made some really good points there about the UI and application
composition. I'm still wondering why the Alt.NET stream didn't accept
them.

What's more important about the whole scope thing - it just feels
natural once you get through the initial learning barrier with
autofac.

3. "Anonymous scope" - that's a nice name. Basically in this scenario
we still have only two scopes - the inner resolution scope that has
multiple layers with component registrations and override and then
there's the scope front (that's where the code "touches" the multiple
scopes of IoC and where the non-singleton components get resolved).

Hm, may be we just need a couple of "IoC in pictures" things just to
show people how these Factory, Singleton and Container things really
play out together in autofac world (and how easy it is to use them)?

4. Could you, please, share the scenarios where lifestyle pinning is
necessary?

5. Well, as I've been saying - the beauty of your IoC container is
that it is small, has nice logics and just works.

So far I didn't have any big urge to hack it or even add anything. The
ResolveByName and proper handling of this was just one minor thing,
but sending in a IResolver interface just did the trick. May be there
could be "Autofac.Contrib" library once there is a reasonable number
of some non-integration helper classes that consistently prove to be
useful.

The only decent problem is that I fear the code bloat of the core
library. But that's a problem with me))

Rinat

PS: Resolving delegates does not feel to be a good idea after all. At
least - not right now. I just cannot justify saving a couple of LOC in
the constructor declaration at the price of maintainability and
testability problems.

On 29 фев, 07:43, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

[Nicholas Blumhardt]

1. LOL! I just wish I could increase the default on Saturdays and
Sundays...

2. That is *really* interesting - I'm going to have to spend some time
with OB1. There are some more observations being made over at
"Alkampfer's Place" - http://www.nablasoft.com/Alkampfer/?p=105 - in
the later linked post, the blogger presents a scope-based solution
more similar to Autofac's than the 'component burden' approach
currently being investigated for MicroKernel.

3. Agreed. I currently like the way that the main project site leads
straight into Autofac rather than general IoC stuff (as noted by
Justin Rudd - http://justinrudd.wordpress.com/2008/02/10/state-of-the-art-for-net-dependency-injection)
- it suits the present target audience. Given Autofac's differences
from other containers, an introductory-level resource is definitely
required to help more people to get productive with it while avoiding
'headaches.' Post-1.1 I was planning to do a CodeProject article that
could meet this need - when that comes around let's discuss, it would
be nice to create an 'open source' article perhaps through this
list...

4. Session-scoped components in an Application->Session->Request style
web scenario? Really in any tree of containers that is deeper than 2,
where components need to have container-scope at a level other than
the root or the leaves. Probably rare in practice but definitely
something that will come up. The same effect could be obtained by
registering singleton components in the appropriate child containers,
however I want to make it possible for all components to be registered
in the root to simplify things like facility construction later on
(all of the available components can be reasoned about in one place.)

5/Core bloat: Autofac.Contrib is pretty much what I've been equating
with Autofac.Extras. Bloat of the core is a big deal to me too,
managing complexity is pretty tough. The current project layout
provides a functioning container with only the Autofac and
Autofac.Component namespaces, though the remainder makes this a lot
more usable. Most people should need only Autofac.dll + integrations,
and 'Extras' will satisfy more complex/advanced needs. A line might be
drawn around Autofac.dll as the set of functionality that will always
be supported by future versions (even if it is through
'Extras.Compatibility_1_1' or similar) while we can add 'Extras'
without worrying too much about maintenance burden.

The builder syntax plus associated registrars could actually be moved
out of the core (though of course they won't be) because they are
supported using only the base Autofac classes and IModule. I have been
thinking for a while about how to make the builder syntax more
extensible - essentially monadic though that's a pretty non-
descriptive term - so it is important for '2.0' that the core remains
isolated even though quite a few 'niceties' live in the same
assembly...

5/Delegate factories: Agreed - it is a fringe feature and very much
belongs in Extras (and the front page no longer links directly to it.)
I'm currently working on an article that I hope explains the scenario
where this approach suits me. Just need to increase that default '24'
by enough that I can fit a surf in this afternoon as well..... :)

Nick

[Rinat Abdullin]

Nick,

1. You can't. That's the hardcoded stuff. However, some debugging
reveals that it's possible to work around this problem by increasing
the frame rate))

2. The architecture behind CAB + OB1 is good. The implementation of
OB1 is not pretty.

3: Justin Rudd. He makes good point on the autofac configuration. That
used to bother me when I was getting used to the module concepts while
leaving the Castle Windsor camp. In Castle you had to write extensive
configs. And the complex logic ("${" and "#{" syntax, shortened
variable/parameter declarations) was there to help with that.

That's not the best approach since it resembles writing some XML-based
DSL to manage the complex registration. However people got used to it.

3: SourceForge article. Yes, open-source article is one of the
solutions. Another one is just to move discussions like this to the
blog scope to prevent the effort from being lost in the groups. And
then you could just pick the pieces you like and copy them to the
autofac wiki. Sourceforge article could be a composition of these blog
bits and wiki bits as well.

4: Tagged scopes. Well you still have to create the child container
branch manually in the code for the Root - Session - Request scenario.
I personally would just register the components or overrides there
manually as well. And if there is a lot of them then there could be
just a SessionModule (no tags, just register it manually on the
freshly-created container). For me that's a cleaner approach than
registering the whole batch in one container and then trying to debug
the logic of "leaf component is not getting the branch-nested
singleton because the last one just could not find one of its neighbor
dependencies".

However that does somewhat rule out the config-based extensibility at
the branch level... I'll have to ponder about that.

5. Yes. Basically the Integration is the kind of Contrib library that
uses some 3rd party project.

6: Delegates. Well, actually I was referring to my wild midnight idea
of stripping ICommand of the class wrapper and directly resolving and
executing some Action<D1,D2,D3> : http://rabdullin.com/why-do-not-we-resolve-delegates-in-ioc/

And about the delegate factories... well, this works for me just fine
so far: Register(c => c.Resolve<IDataStoreProvider>().GetDataLayer())

All the best,
Rinat


On 2 мар, 07:21, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

> 1. LOL! I just wish I could increase the default on Saturdays and
> Sundays...
>
> 2. That is *really* interesting - I'm going to have to spend some time
> with OB1. There are some more observations being made over at

> "Alkampfer's Place" -http://www.nablasoft.com/Alkampfer/?p=105- in

> the later linked post, the blogger presents a scope-based solution
> more similar to Autofac's than the 'component burden' approach
> currently being investigated for MicroKernel.
>
> 3. Agreed. I currently like the way that the main project site leads
> straight into Autofac rather than general IoC stuff (as noted by

> Justin Rudd -http://justinrudd.wordpress.com/2008/02/10/state-of-the-art-for-net-d...)

[Nicholas Blumhardt]

Regarding config-based extensibility at the branch level - could you
achieve that simply using multiple configuration sections in your
config file? The ConfigurationSettingsReader module accepts the name
of the configuration section.

There are two reasons I am not keen on the approach though:

The configuration code (XML and programmatic) is not optimised or even
efficient, so although it won't matter in the vast majority of apps, a
design that requires running confi for every request hitting an app
will eventually be problematic. This might also be relevant once the
reflection-based code caches constructor searches and/or uses LINQ
compilation or DynamicMethod as an optimisation (this is still a bit
of a grey area because the resolution behaviour is so dynamic.)
Opportunities for sharing precompiled activators will be reduced if
the registrations in the child containers are completely separate.

The other issue is that any modules applied to the container with
cross-cutting concerns, i.e. that need to enumerate the registrations
in the container, can currently only be applied to components
registered directly in a container (not inherited.) There is a
workaround but again it has efficiency implications.

I'm not suggesting that registering components in subcontainers be
discouraged, but it should be the exception rather than the rule (if
anyone doing it does hit the problems I listed, then the tagged-
context feature should get them out of trouble.) This area still needs
some documentation - before 1.1 is 'released' I'll try to go over
everything.

Good point about modules vs. XML-based DLS. Glad that has worked out.
I'd still like to add #{ etc some day, but they're not really vital.

Nick

On Mar 2, 5:57 pm, Rinat Abdullin <rinat.abdul...@gmail.com> wrote:
> Nick,
>

> ...
>
> read more >>