Loading ...
Sorry, an error occurred while loading the content.
 

RE: [nservicebus] IoC container

Expand Messages
  • Udi Dahan
    Jørn, You would need to register the types you want injected to your handler in the container. You can do this directly into your container of choice, or if
    Message 1 of 31 , May 17, 2009

      Jørn,

       

      You would need to register the types you want injected to your handler in the container.

      You can do this directly into your container of choice, or if you'd prefer to stick to the nServiceBus abstraction you could do it like so:

       

      NServiceBus.Configure.With().CastleWindsorBuilder(

      (cfg => cfg.ConfigureComponent<MyType>(ComponentModel.Singlecall or Singleton))

      )

      . // everything else

       

      And then you'd just have a property of MyType on your message handler (or a constructor accepting that type as an argument).

       

      Does that answer your question?

       

      -- Udi Dahan

       

      From: nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] On Behalf Of Jørn Wildt
      Sent: Sunday, May 17, 2009 3:16 PM
      To: nservicebus@yahoogroups.com
      Subject: [nservicebus] IoC container

       




      In the pub/sub sample there's an IBus property in the handler class. This is not part of IMessageHandler but gets set anyway. I assume this is because of some IoC mechanism used to instantiate the handlers. Can anyone point me to which container nServiceBus uses and how I configure it?

      In my scenario I have a couple of extra dependencies for my message handlers - internal services and repositories for them to use, and I want those to be available in the same way as the injected Bus reference.

      Thanks.

      /Jørn

    • Udi Dahan
      David, You re absolutely right - last year things were in a much different place. Much of the work done on the configuration model since then was to solidify
      Message 31 of 31 , May 19, 2009

        David,

         

        You're absolutely right - last year things were in a much different place.

        Much of the work done on the configuration model since then was to solidify the approach towards these groups.

         

        > Instances simply took references to their dependencies in their constructors

         

        Is that how you wrote your web service classes as well? Message handlers are conceptually similar to those.

         

        > I couldn't even use nServiceBus's container abstraction (which would have put me in group 2a),

        > because it makes significant assumptions about the design of the registered classes (try registering a class without a default constructor

         

        That's exactly the reasoning behind the work done and being done to the config model.

        Now that we've done away with the proxying of classes, we can register classes without a default constructor (see Andreas' post: http://andreasohlund.blogspot.com/2009/05/nservicebus-support-for-structuremap.html).

         

        > I just wanted to correct what I felt was a strong misconception in your most recent analysis

         

        First of all let me thank you for bringing this up because I'm guessing that many people were wondering.

        Second, I absolutely concede that things aren't where they should/could be and more work needs to be done.

        Third, the analysis describes the direction we're going in and why, particularly about better serving users in groups 1 and 2A where, so far, nServiceBus has primarily been a 2B set of libraries. We're going through some growing pains in trying to find the right model to serving all groups, but each step does seem to be bringing us closer.

         

        > that developers can choose not to care about the container and still use nServiceBus

         

        I am currently consulting two large clients who fit that description and they seem to be quite happy with the *current* state of affairs. They probably wouldn't have been as happy if they were working on last year's nServiceBus.

         

        Thanks for sharing your experiences, thoughts, and concerns with us David.

        They are most helpful and appreciated.

         

        -- Udi Dahan

         

        From: nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] On Behalf Of dncomputerboy
        Sent: Tuesday, May 19, 2009 11:21 PM
        To: nservicebus@yahoogroups.com
        Subject: [nservicebus] Re: IoC container

         




        I have to dispute the claim made about group 1. I started integrating nServiceBus into my application over a year ago, and the biggest problem that I had was working around nServiceBus's requirement for a container. Our application did not use a container at the time; neither did we employ static singleton objects. Instances simply took references to their dependencies in their constructors, and those dependencies were supplied when the object was constructed.

        If nServiceBus had supplied a factory interface that gave my application control over instantiating message handlers, the integration would have been trivial. However, since no such interface was available, the only other option for providing my message handlers with the context they needed was to take a direct dependency on a container and register my objects manually. I couldn't even use nServiceBus's container abstraction (which would have put me in group 2a), because it makes significant assumptions about the design of the registered classes (try registering a class without a default constructor; see this thread for more: http://tech.groups.yahoo.com/group/nservicebus/message/1785). So I was forced into group 2b, despite having almost no knowledge of or interest in using a container, solely because of the design of nServiceBus.

        My conclusion is that group 1 cannot even exist except in the most trivial of circumstances, and group 2a can only exist if the target application is written from the beginning with nServiceBus in mind. Anyone else must be in group 2b, whether they want to be or not. If the consequences of that are well understood and accepted as a result of the way nServiceBus is designed, that's fine. I just wanted to correct what I felt was a strong misconception in your most recent analysis, that developers can choose not to care about the container and still use nServiceBus; in my opinion, that's not realistically possible while still maintaining a well-factored design.

        David

        --- In nservicebus@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@...> wrote:

        >
        > Let's rein this in a bit.
        >
        >
        >
        > There are two main groups of users we're looking at here - those who use a
        > container, and those who don't.
        >
        >
        >
        > (1) The group that don't use a container don't want to have to deal with
        it.
        > I've never heard a complaint from this group about the way nServiceBus
        > instantiates their handlers, sagas, etc. One of the reasons for that is
        that
        > they don't need to inject anything into those objects, so couldn't really
        > care about how they're instantiated. Any dependencies they need they'll
        > often go and get using some static gateway in their own code, or just new
        up
        > the relevant classes.
        >
        >
        >
        > (2A) The group that uses a container is actually 2 sub groups - one that
        > uses basic dependency injection capabilities and doesn't necessarily
        > use/need the latest and greatest feature of their container (working off
        of
        > a release of the container, not its main trunk). Letting this group
        specify
        > which container nServiceBus will use (so that it's the same as what they
        > already know and use) often covers things for them.
        >
        >
        >
        > (2B) The second sub-group often work off of the trunk of nServiceBus, as
        > well as their container, and need more control than the other two groups.
        > Usually not more control in terms of how their objects are instantiated,
        but
        > rather control over the versions of the various projects their working
        with
        > so that everything stays compatible. This group does *not* want a
        framework
        > - but rather a library that they can manage like everything else. That
        group
        > is best served by taking the granular assemblies that make up nServiceBus
        > and using them. In short, they won't be using or taking any of the
        container
        > adapters that come with nServiceBus.
        >
        >
        >
        > *
        >
        >
        >
        > Users in group 2A don't want to have to write their own container adapter
        to
        > work with nServiceBus, so it should be packaged in.
        >
        > Users in group 1 don't care as long as it doesn't mean any extra work for
        > them, so will use whatever's packaged in.
        >
        > Users in group 2B will *not* be able to navigate the waters of version
        > conflicts without using the independent pieces of nServiceBus, so beyond
        > having access to a build that doesn't merge in those 3rd party assemblies,
        > don't care either.
        >
        >
        >
        > The problems that were happening were when users in group 2B tried to use
        a
        > build that was designed for the other groups.
        >
        >
        >
        > *
        >
        >
        >
        > Wrapping this up - nServiceBus is designed the way it is so that all
        groups
        > get a solution that is as simple as possible for their situation, but no
        > simpler.
        >
        >
        >
        > Some independent pieces of nServiceBus need to have a container available
        to
        > them.
        >
        > While we could say that "any NSB user *must* supply a container
        instance to
        > use ", that wouldn't serve group 1, and would be more work than group
        2A
        > wants - so other pieces of nServiceBus supply some intelligent default
        > containers that just work.
        >
        > Wrapping all of the above pieces into a single assembly also best serves
        > groups 1 and 2A in that it keeps references simple.
        >
        > As such, it can't be expected that it would serve group 2B well at all.
        >
        >
        >
        > There is no internal container or external container - there should only
        be
        > one container.
        >
        > Groups 1 and 2A will use what's in the box, group 2B will provide their
        > own.
        >
        > The various builds of nServiceBus (all included & core only) will give
        each
        > group what they need.
        >
        >
        >
        > The only thing is that we need to be clearer in terms of documentation
        > targeted at group 2B what they need to do to get what they want.
        >
        >
        >
        > *
        >
        >
        >
        > Finally, one of the advantages of having a container is that we don't have
        > to go and create a factory for every type of thing we instantiate. The
        fact
        > that existing frameworks haven't taken advantage of containers (yet) is
        more
        > due to their history and backwards compatibility requirements than because
        > their creators think the factory model is better. Expect more frameworks
        > (including those coming from Microsoft) to go down the container route,
        > using things like MEF.
        >
        >
        >
        > *
        >
        >
        >
        > Hope that clears up what was done why as well as for whom.
        >
        > Looking at pleasing most people most of the time.
        >
        >
        >
        > Best regards,
        >
        >
        >
        > -- Udi Dahan
        >
        >
        >
        > From: nservicebus@yahoogroups.com
        [mailto:nservicebus@yahoogroups.com] On
        > Behalf Of jeremie.chassaing
        > Sent: Tuesday, May 19, 2009 4:57 PM
        > To: nservicebus@yahoogroups.com
        > Subject: [nservicebus] Re: IoC container
        >
        >
        >
        >
        >
        >
        >
        >
        > Someone has hacked my enter key !
        >
        > Seriously, there is surely no critical need to have a container to
        > instantiate handlers, there is probably a way to turn things so you dont
        > need it.
        >
        > Using a container interface to do the work of a IMessageHandlerFactory is
        an
        > over abstraction IMO.
        >
        > --- In nservicebus@yahoogroups.com
        <mailto:nservicebus%40yahoogroups.com> ,
        > "Eben Roux" <eben@> wrote:
        > >
        > > Hey Jeremie & all,
        > >
        > > I think your enter key is putting an exclamation into your sentences
        :)
        > >
        > > OK, I have not *really* been following this thread but I think I get
        the
        > gist of it.
        > >
        > > Maybe it would be a good idea to decouple the IoC container for NSB
        from
        > the client (of NSB).
        > >
        > > Regards,
        > > Eben
        > >
        > > --- In nservicebus@yahoogroups.com
        <mailto:nservicebus%40yahoogroups.com>
        > , "jeremie.chassaing" <jeremie.chassaing@> wrote:
        > > >
        > > > Why should we provide NSB (or any framework) a container !
        > > >
        > > > We don't want, or need to have anything to do with the
        framework's
        > internal components instantiation !
        > > > The only thing that can come from this is unexpected behaviors
        and bugs
        > !
        > > >
        > > >
        > > > The only point at which we care about instantiation is when the
        > framework instanciate our own objects.
        > > >
        > > > But specific interfaces (like ASP.Net IHttpHandlerFactory) are
        far
        > enough to handle this case !
        > > >
        > > > Don't need tricky ICommonServiceLocator interface with loads of
        methods
        > for that !
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > --- In nservicebus@yahoogroups.com
        > <mailto:nservicebus%40yahoogroups.com> , Jørn Wildt <jw@>
        wrote:
        > > > >
        > > > > Jeremie mentions in his blog that the IoC container should
        be internal
        > to NSB. I tend to agree with this. Why don't NSB just choose *one*
        > implementation, hide it from the end user, and then stick to that. I, as a
        > NSB user, don't need to know what container NSB uses.
        > > > >
        > > > > Then I can use what ever container I like for the rest of
        my
        > application - and if NSB supplies a "object creation hook" (as
        mentioned
        > below) then I can stick my container call in there - or NSB can use it's
        own
        > internal container.
        > > > >
        > > > > You can also turn it the other way around: any NSB user
        *must* supply
        > a container instance to use, completely eliminating the need for an
        internal
        > container.
        > > > >
        > > > > I think you will have trouble with the current setup if NSB
        uses one
        > version of a container whereas my application uses another version (of the
        > same container of course).
        > > > >
        > > > > Does that make sense or have I overlooked something?
        > > > >
        > > > > It's the never ending story of "who owns library A
        when library B
        > depends on A - the application or library B?".
        > > > >
        > > > > /Jørn
        > > > >
        > > > > --- In nservicebus@yahoogroups.com
        > <mailto:nservicebus%40yahoogroups.com> , "Udi Dahan"
        <thesoftwaresimplist@>
        > wrote:
        > > > > >
        > > > > > > cfg.ConfigureProperty<MyHandler>(h =>
        h.MyProp, MyValue);
        > > > > >
        > > > > >
        > > > > >
        > > > > > This is now on the trunk.
        > > > > >
        > > > > >
        > > > > >
        > > > > > Maybe the thing is that none of the builders *need* to
        accept a
        > > > > > user-provided technology-specific container like:
        > > > > >
        > > > > >
        > > > > >
        > > > > > CastleWindsorBuilder(IWindsorContainer)
        > > > > >
        > > > > >
        > > > > >
        > > > > > In other words, you just pick either
        CastleWindsorBuilder,
        > SpringBuilder,
        > > > > > StructureMapBuilder, AutoFacBuilder, or whatever else
        that will come
        > in the
        > > > > > box that you fancy, and be done with it.
        > > > > >
        > > > > >
        > > > > >
        > > > > > Maybe we've got everything covered as is by just
        choosing which
        > builder you
        > > > > > want, since your user code can configure everything in
        a
        > container-agnostic
        > > > > > way.
        > > > > >
        > > > > >
        > > > > >
        > > > > > Power users can always provide their own adapter to
        their own
        > specific
        > > > > > container / version of container, and not worry about
        anything
        > exposed
        > > > > > causing versioning conflicts. All of the pieces of
        nServiceBus would
        > then
        > > > > > use that adapter to configure themselves into it. This
        seems like
        > the best
        > > > > > tradeoff.
        > > > > >
        > > > > >
        > > > > >
        > > > > > I'm actually leaning quite heavily in this direction.
        > > > > >
        > > > > >
        > > > > >
        > > > > > Thoughts?
        > > > > >
        > > > > >
        > > > > >
        > > > > > -- Udi Dahan
        > > > > >
        > > > > >
        > > > > >
        > > > > > From: Udi Dahan [mailto:thesoftwaresimplist@]
        > > > > > Sent: Tuesday, May 19, 2009 1:12 PM
        > > > > > To: 'nservicebus@yahoogroups.com
        > <mailto:%27nservicebus%40yahoogroups.com> '
        > > > > > Subject: RE: [nservicebus] Re: IoC container
        > > > > >
        > > > > >
        > > > > >
        > > > > > Jeremie,
        > > > > >
        > > > > >
        > > > > >
        > > > > > You were suggesting that nServiceBus take control of
        the creation
        > process
        > > > > > and allow you to specify things you wanted to have
        injected into
        > your
        > > > > > message handlers without necessarily knowing about the
        specific
        > container.
        > > > > >
        > > > > >
        > > > > >
        > > > > > That is already there.
        > > > > >
        > > > > >
        > > > > >
        > > > > > If you don't care about which container is used, just
        pick one and
        > go about
        > > > > > your business.
        > > > > >
        > > > > >
        > > > > >
        > > > > > Then, specify actions you want on your types:
        > > > > >
        > > > > >
        > > > > >
        > > > > > var bus = NServiceBus.Configure.With()
        > > > > >
        > > > > > .CastleWindsorBuilder(
        > > > > >
        > > > > > cfg => {
        > > > > >
        > cfg.ConfigureComponent<MyHandler>(ComponentCallModel.Singlecall).ConfigurePr
        > > > > > operty( h => h.MyProp, MyValue ); }
        > > > > >
        > > > > > )
        > > > > >
        > > > > > . //everything else
        > > > > >
        > > > > >
        > > > > >
        > > > > > Although you have given me an idea.
        > > > > >
        > > > > >
        > > > > >
        > > > > > You shouldn't have to do the first part (since you may
        not know what
        > the
        > > > > > right ComponentCallModel should be), you should be
        able to simply
        > do:
        > > > > >
        > > > > >
        > > > > >
        > > > > > cfg.ConfigureProperty<MyHandler>(h =>
        h.MyProp, MyValue);
        > > > > >
        > > > > >
        > > > > >
        > > > > > Cool - will have that done shortly.
        > > > > >
        > > > > >
        > > > > >
        > > > > > -- Udi Dahan
        > > > > >
        > > > > >
        > > > > >
        > > > > > From: nservicebus@yahoogroups.com
        > <mailto:nservicebus%40yahoogroups.com> [mailto:
        href="mailto:nservicebus%40yahoogroups.com">nservicebus@yahoogroups.com
        > <mailto:nservicebus%40yahoogroups.com> ] On
        > > > > > Behalf Of jeremie.chassaing
        > > > > > Sent: Monday, May 18, 2009 12:44 PM
        > > > > > To: nservicebus@yahoogroups.com
        > <mailto:nservicebus%40yahoogroups.com>
        > > > > > Subject: [nservicebus] Re: IoC container
        > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > > >
        > > > > > I wrote a blog post about this issue recently, and the
        current way
        > to
        > > > > > integrate IOC containers in the framework raises some
        issues (but
        > it's not
        > > > > > specific to NServiceBus and event to messaging
        frameworks...)
        > > > > >
        > > > > > You can read the full post here :
        > > > > >
        href="http://thinkbeforecoding.com/post/2009/05/15/IOC-container-go-hide">http://thinkbeforecoding.com/post/2009/05/15/IOC-container-go-hide
        > > > > >
        > > > > > I've talked with udi about it on twitter, but I don't
        know what are
        > his
        > > > > > plans about it for NServiceBus..
        > > > > >
        > > > > > --- In nservicebus@yahoogroups.com
        > <mailto:nservicebus%40yahoogroups.com>
        > <mailto:nservicebus%40yahoogroups.com> ,
        > > > > > Jørn Wildt <jw@> wrote:
        > > > > > >
        > > > > > > > Admins shouldn't (as a rule) change
        important developer
        > assumptions
        > > > > > (like
        > > > > > > > the component model) so we don't put it out
        there where it can
        > be
        > > > > > > > accidentally changed.
        > > > > > > >
        > > > > > > > Does that make sense?
        > > > > > >
        > > > > > > Yes. Thanks. I guess "important developer
        assumptions" depends a
        > lot on
        > > > > > your scenario. But let's save that discussion for
        another time, I
        > have made
        > > > > > enough noise here already.
        > > > > > >
        > > > > > > /Jørn
        > > > > > >
        > > > > > > --- In
        href="mailto:nservicebus%40yahoogroups.com">nservicebus@yahoogroups.com
        > <mailto:nservicebus%40yahoogroups.com>
        > <mailto:nservicebus%40yahoogroups.com>
        > > > > > , "Udi Dahan" <thesoftwaresimplist@>
        wrote:
        > > > > > > > > What if I want to write that in the XML
        app.config? [...]when
        > to do it
        > > > > > > > programmatically?
        > > > > > > >
        > > > > > > > If the thing being configured is for a
        developer to decide, do
        > it
        > > > > > > > programmatically. If an admin is going to be
        configuring it -
        > put it in
        > > > > > the
        > > > > > > > app.config.
        > > > > > > >
        > > > > > > > This is the principle that was also used to
        decide how the
        > various parts
        > > > > > of
        > > > > > > > nServiceBus would be configured.
        > > > > > > >
        > > > > > > > Admins shouldn't (as a rule) change
        important developer
        > assumptions
        > > > > > (like
        > > > > > > > the component model) so we don't put it out
        there where it can
        > be
        > > > > > > > accidentally changed.
        > > > > > > >
        > > > > > > > Does that make sense?
        > > > > > >
        > > > > >
        > > > >
        > > >
        > >
        >

      Your message has been successfully submitted and would be delivered to recipients shortly.