Are you building an API layer that is meant to be completely
self-contained and reused in any context? If so, there are some
additional questions that need to be answered:

- Are you looking to Ninject to stitch together your own internal
dependencies or is it as a way for consumers of your API to swap out
pieces for their own implementations as well?
- If I'm using your API, can I use my own container or do I have to use Ninject?
- If I can swap out pieces of your API can I use my own container to
supply those pieces?

If not, you'd probably be better served by moving away from using
Ninject as an "object factory" and more along the lines of a
"dependency registry" and simply declaring dependencies as constructor
arguments or properties. You could have a default Ninject module that
registers all of your dependency concrete implementations
(ICustomerRegistry bound to CustomerRegistry, etc...) and then a
consumer of your API could use your Ninject module say in a web
application or web service host to resolve dependencies at runtime.
Let's say you were using ASP.NET MVC - in the module you have a
controller implementation registered which has constructor-based
dependencies on IFooRepository and IBarRepository. Those are bound to
FooRepository and BarRepository respectively in the module. When an
instance of the controller is requested Ninject will supply the
dependencies automatically.

Hope that helps,
Matt

On Tue, Jul 14, 2009 at 1:00 PM, Justin Daubenmire<jdaubenm@...> wrote:
> Below is a simplistic example making use of 4 assemblies "IOC", "Domain",
> "Repositories" and "Services".
>
>
>
> The "IOC" assembly contains two classes: 1) The DI container for Ninject,
> and 2) a class that serves as a Ninject Module where the binding rules are
> defined.
>
> The following article was the inspiration for this:
>
>
http://www.codethinked.com/post/2008/08/21/Creating-a-binding-factory-for-Ninjec\
t.aspx
>
>
>
> The "Repositories" assembly will create Domain objects using Ninject
>
> * The "Repositories" assembly needs a reference to "IOC" to invoke the DI
> container for the creation of Domain objects.
>
> * The Domain object bindings need defined in the Ninject Module in the "IOC"
> assembly. As a result, the "IOC" assembly needs a reference to "Domain"
>
>
>
> The "Services" assembly will create Repository objects using Ninject
>
> * The "Services" assembly needs a reference to "IOC" to invoke the DI
> container for the creation of Repository objects.
>
> * The Repository object bindings need defined in the Ninject Module in the
> "IOC" assembly. As a result, the "IOC" assembly need a reference to
> "Repositories"
>
>
>
> At this point the circular dependency looks like this:
>
> "Repositories" -> "IOC" -> "Repositories"
>
>
>
> Hopefully that helps clear up the madness.
>
>
>
> Any suggestions on how I could have done this better?
>
>
>
> Thanks for any feedback!
>
>
>
> Regards,
> Justin
> ----- Original Message -----
> From: "Michael Hart" <michael.hart.au@...>
> To: <domaindrivendesign@yahoogroups.com>
> Sent: Tuesday, July 14, 2009 9:48 AM
> Subject: Re: [domaindrivendesign] IOC circular dependency question
>
>
>> Hi Justin,
>>
>> So it's this step I don't understand:
>>
>>> At any time I need a concrete instance of something in the API, I
>>> add a
>>> reference of MyAppxxx.dll assembly to the IOC assembly.
>>
>> What is this "IOC" assembly? I don't quite get what its purpose is.
>> Can you give an example of a class from that assembly and how you use
>> it?
>>
>> If you're creating a set of libraries, with no entry point, then how
>> are you using your IoC container? You typically only need a container
>> when you're instantiating your app and you want to define which
>> specific implementations get injected.
>>
>> Cheers,
>>
>> Michael
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>