Re: Dependency injection

[Wayne Molina]

IMO use DI only on objects where you need to change the object but keep the
flow the same.  Dont use it just for the sake of using DI

[Dotan N.]

unit/integration testing will show you the sweet spot

On Wed, Feb 16, 2011 at 6:22 PM, Wayne Molina <wayne.molina@...>wrote:

>
>
> IMO use DI only on objects where you need to change the object but keep the
> flow the same.  Dont use it just for the sake of using DI
>
>  
>

[Steven Smith-23]

Also remember to follow the Single Responsibility Principle.  If your
classes have more than a couple of things being injected, it's often a sign
they are doing too much.  I have a few blog posts outlining some things that
are dependencies/responsibilities that should be separated out into other
classes:

http://stevesmithblog.com/blog/avoid-entrenched-dependencies/
http://stevesmithblog.com/blog/avoiding-dependencies/
http://stevesmithblog.com/blog/insidious-dependencies/

You can also look at things like AOP for cross-cutting concerns like logging
as a way to add these things into your system without having them clutter up
your classes.

Steve


On Wed, Feb 16, 2011 at 11:24 AM, Dotan N. <dipidi@...> wrote:

>
>
> unit/integration testing will show you the sweet spot
>
>
> On Wed, Feb 16, 2011 at 6:22 PM, Wayne Molina <wayne.molina@...>wrote:
>
>>
>>
>> IMO use DI only on objects where you need to change the object but keep
>> the flow the same.  Dont use it just for the sake of using DI
>>
>>
>  
>

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

[kogerbnz]

> unit/integration testing will show you the sweet spot
>
So are you saying that I should really only be using DI as seams for  tests?

[Dotan N.]

I'm saying, once you unit test / integration test properly, you'll discover
the parts that are too sticky. It'll force you into more modular design, and
then you'll see how the modules grow apart.
These modules will depend upon each other in various ways, and it'll be the
DI's job to inject the dependencies.

On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...> wrote:

>
>
> > unit/integration testing will show you the sweet spot
> >
> So are you saying that I should really only be using DI as seams for tests?
>
>  
>

[Serhat Özgel]

In my case, we have a web app that has lots of modules. A business layer
class has 5-6 dependencies on the average. We try to follow solid strictly,
not perfect but almost there. The problem is, we have hundreds of classes
that we register into our ioc container and it is growing. The registrations
alone take nearly 10 seconds on app init. How would you deal with such a
situation? Is it ok to have  hundreds or thousands of registrations in an
app?

On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:

>
>
> I'm saying, once you unit test / integration test properly, you'll discover
> the parts that are too sticky. It'll force you into more modular design, and
> then you'll see how the modules grow apart.
> These modules will depend upon each other in various ways, and it'll be the
> DI's job to inject the dependencies.
>
>
> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...> wrote:
>
>>
>>
>> > unit/integration testing will show you the sweet spot
>> >
>> So are you saying that I should really only be using DI as seams for
>> tests?
>>
>>
>  
>

[Steven Smith-23]

What IOC container are you using that takes 10 seconds to wire up 1000 types
on startup?

Steve


On Wed, Feb 16, 2011 at 5:36 PM, Serhat Özgel <serhatozgel@...> wrote:

>
>
> In my case, we have a web app that has lots of modules. A business layer
> class has 5-6 dependencies on the average. We try to follow solid strictly,
> not perfect but almost there. The problem is, we have hundreds of classes
> that we register into our ioc container and it is growing. The registrations
> alone take nearly 10 seconds on app init. How would you deal with such a
> situation? Is it ok to have  hundreds or thousands of registrations in an
> app?
>
>
> On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:
>
>>
>>
>> I'm saying, once you unit test / integration test properly, you'll
>> discover the parts that are too sticky. It'll force you into more modular
>> design, and then you'll see how the modules grow apart.
>> These modules will depend upon each other in various ways, and it'll be
>> the DI's job to inject the dependencies.
>>
>>
>> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...> wrote:
>>
>>>
>>>
>>> > unit/integration testing will show you the sweet spot
>>> >
>>> So are you saying that I should really only be using DI as seams for
>>> tests?
>>>
>>>
>>
>  
>

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

[Serhat Özgel]

We are using Castle Windsor. A fraction of this time may be taken by
initializing nhibernate session or configuration facilities so I may have
been wrong taking initialization time into consideration. My main issue is,
we have too much dependencies that I am starting to think we are doing
something wrong.

On Thu, Feb 17, 2011 at 5:44 PM, Steven Smith <ssmith.lists@...>wrote:

>
>
> What IOC container are you using that takes 10 seconds to wire up 1000
> types on startup?
>
> Steve
>
>
>
> On Wed, Feb 16, 2011 at 5:36 PM, Serhat Özgel <serhatozgel@...>wrote:
>
>>
>>
>> In my case, we have a web app that has lots of modules. A business layer
>> class has 5-6 dependencies on the average. We try to follow solid strictly,
>> not perfect but almost there. The problem is, we have hundreds of classes
>> that we register into our ioc container and it is growing. The registrations
>> alone take nearly 10 seconds on app init. How would you deal with such a
>> situation? Is it ok to have  hundreds or thousands of registrations in an
>> app?
>>
>>
>> On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:
>>
>>>
>>>
>>> I'm saying, once you unit test / integration test properly, you'll
>>> discover the parts that are too sticky. It'll force you into more modular
>>> design, and then you'll see how the modules grow apart.
>>> These modules will depend upon each other in various ways, and it'll be
>>> the DI's job to inject the dependencies.
>>>
>>>
>>> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...> wrote:
>>>
>>>>
>>>>
>>>> > unit/integration testing will show you the sweet spot
>>>> >
>>>> So are you saying that I should really only be using DI as seams for
>>>> tests?
>>>>
>>>>
>>>
>>
>
>
> --
> Steve Smith
> http://SteveSmithBlog.com/
> http://twitter.com/ardalis
>
>  
>

[Derek Greer]

Let's see your registration code.  Perhaps there's some inefficiencies in
how you are going about  that can be improved upon.

Derek


On Wed, Feb 16, 2011 at 4:36 PM, Serhat Özgel <serhatozgel@...> wrote:

>
>
> In my case, we have a web app that has lots of modules. A business layer
> class has 5-6 dependencies on the average. We try to follow solid strictly,
> not perfect but almost there. The problem is, we have hundreds of classes
> that we register into our ioc container and it is growing. The registrations
> alone take nearly 10 seconds on app init. How would you deal with such a
> situation? Is it ok to have  hundreds or thousands of registrations in an
> app?
>
>
> On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:
>
>>
>>
>> I'm saying, once you unit test / integration test properly, you'll
>> discover the parts that are too sticky. It'll force you into more modular
>> design, and then you'll see how the modules grow apart.
>> These modules will depend upon each other in various ways, and it'll be
>> the DI's job to inject the dependencies.
>>
>>
>> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...> wrote:
>>
>>>
>>>
>>> > unit/integration testing will show you the sweet spot
>>> >
>>> So are you saying that I should really only be using DI as seams for
>>> tests?
>>>
>>>
>>
>  
>

--
Derek Greer
Email: dbgreer@...
<dbgreer@...>Twitter: @derekgreer <http://twitter.com/derekgreer>
Blog: http://aspiringcraftsman.com

[Steven Smith-23]

Maybe you are doing something wrong, maybe not.  I don't know that we on the
list have enough information to guide you one way or the other.  Can you
share a particular example that concerns you?

On Thu, Feb 17, 2011 at 10:47 AM, Serhat Özgel <serhatozgel@...>wrote:

>
>
> We are using Castle Windsor. A fraction of this time may be taken by
> initializing nhibernate session or configuration facilities so I may have
> been wrong taking initialization time into consideration. My main issue is,
> we have too much dependencies that I am starting to think we are doing
> something wrong.
>
> On Thu, Feb 17, 2011 at 5:44 PM, Steven Smith <ssmith.lists@...>wrote:
>
>>
>>
>> What IOC container are you using that takes 10 seconds to wire up 1000
>> types on startup?
>>
>> Steve
>>
>>
>>
>> On Wed, Feb 16, 2011 at 5:36 PM, Serhat Özgel <serhatozgel@...>wrote:
>>
>>>
>>>
>>> In my case, we have a web app that has lots of modules. A business layer
>>> class has 5-6 dependencies on the average. We try to follow solid strictly,
>>> not perfect but almost there. The problem is, we have hundreds of classes
>>> that we register into our ioc container and it is growing. The registrations
>>> alone take nearly 10 seconds on app init. How would you deal with such a
>>> situation? Is it ok to have  hundreds or thousands of registrations in an
>>> app?
>>>
>>>
>>> On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:
>>>
>>>>
>>>>
>>>> I'm saying, once you unit test / integration test properly, you'll
>>>> discover the parts that are too sticky. It'll force you into more modular
>>>> design, and then you'll see how the modules grow apart.
>>>> These modules will depend upon each other in various ways, and it'll be
>>>> the DI's job to inject the dependencies.
>>>>
>>>>
>>>> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...> wrote:
>>>>
>>>>>
>>>>>
>>>>> > unit/integration testing will show you the sweet spot
>>>>> >
>>>>> So are you saying that I should really only be using DI as seams for
>>>>> tests?
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Steve Smith
>> http://SteveSmithBlog.com/
>> http://twitter.com/ardalis
>>
>>
>  
>

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

[Serhat Özgel]

It is less or more like this:

Controllers are mvc controllers, which get data from client, converts it
into dtos and passes to services. Repositories generally contain unique
methods to that domain. A common repository is used for common stuff like
simple selects, crud, etc. Business logic goes to services and services
already contain lots of code so  it would not be a good idea to reduce their
numbers (we must do the opposite).

_container.Register(Component.For<IKController>().ImplementedBy<KController>().LifeStyle.Transient);
_container.Register(Component.For<IYController>().ImplementedBy<YController>().LifeStyle.Transient);
_container.Register(Component.For<IZController>().ImplementedBy<ZController>().LifeStyle.Transient);
(goes on for 100 lines)
...
_container.Register(Component.For<IKService>().ImplementedBy<KService>().LifeStyle.Transient);
_container.Register(Component.For<ILService>().ImplementedBy<LService>().LifeStyle.Transient);
_container.Register(Component.For<IMService>().ImplementedBy<MService>().LifeStyle.Transient);
(goes on for 300 lines)
...
_container.Register(Component.For<IDomainXRepository>().ImplementedBy<XDomainRepository>().LifeStyle.Transient);
_container.Register(Component.For<IDomainYRepository>().ImplementedBy<YDomainRepository>().LifeStyle.Transient);
_container.Register(Component.For<IDomainZRepository>().ImplementedBy<ZDomainRepository>().LifeStyle.Transient);
(goes on for 200 lines)
...
_container.Register(Component.For<IEncryptor>().ImplementedBy<BcryptEncryptor>());
._container.Register(Component.For<IJsonSerializer>().ImplementedBy<Serialization.Impl.JsonSerializer>());
_container.Register(Component.For<IResourceReader>().ImplementedBy<ResourceReader>());
_container.Register(Component.For<IXmlSerializer>().ImplementedBy<XmlSerializer>());
_container.Register(Component.For<IUnitOfWorkFactory>().ImplementedBy<UnitOfWorkFactory>().LifeStyle.Transient);
(goes on for 50 lines for utility stuff)
...
[registrations for other stuff like imports, web services, etc.]
(goes on for 50 lines)
...

On Thu, Feb 17, 2011 at 5:52 PM, Steven Smith <ssmith.lists@...>wrote:

>
>
> Maybe you are doing something wrong, maybe not.  I don't know that we on
> the list have enough information to guide you one way or the other.  Can you
> share a particular example that concerns you?
>
>
> On Thu, Feb 17, 2011 at 10:47 AM, Serhat Özgel <serhatozgel@...>wrote:
>
>>
>>
>> We are using Castle Windsor. A fraction of this time may be taken by
>> initializing nhibernate session or configuration facilities so I may have
>> been wrong taking initialization time into consideration. My main issue is,
>> we have too much dependencies that I am starting to think we are doing
>> something wrong.
>>
>> On Thu, Feb 17, 2011 at 5:44 PM, Steven Smith <ssmith.lists@...>wrote:
>>
>>>
>>>
>>> What IOC container are you using that takes 10 seconds to wire up 1000
>>> types on startup?
>>>
>>> Steve
>>>
>>>
>>>
>>> On Wed, Feb 16, 2011 at 5:36 PM, Serhat Özgel <serhatozgel@...>wrote:
>>>
>>>>
>>>>
>>>> In my case, we have a web app that has lots of modules. A business layer
>>>> class has 5-6 dependencies on the average. We try to follow solid strictly,
>>>> not perfect but almost there. The problem is, we have hundreds of classes
>>>> that we register into our ioc container and it is growing. The registrations
>>>> alone take nearly 10 seconds on app init. How would you deal with such a
>>>> situation? Is it ok to have  hundreds or thousands of registrations in an
>>>> app?
>>>>
>>>>
>>>> On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:
>>>>
>>>>>
>>>>>
>>>>> I'm saying, once you unit test / integration test properly, you'll
>>>>> discover the parts that are too sticky. It'll force you into more modular
>>>>> design, and then you'll see how the modules grow apart.
>>>>> These modules will depend upon each other in various ways, and it'll be
>>>>> the DI's job to inject the dependencies.
>>>>>
>>>>>
>>>>> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> > unit/integration testing will show you the sweet spot
>>>>>> >
>>>>>> So are you saying that I should really only be using DI as seams for
>>>>>> tests?
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Steve Smith
>>> http://SteveSmithBlog.com/
>>> http://twitter.com/ardalis
>>>
>>>
>>
>
>
> --
> Steve Smith
> http://SteveSmithBlog.com/
> http://twitter.com/ardalis
>
>  
>

[Ernst Kuschke]

Of course, time spent on initialization might not be because of the container, but rather because of what your objects are doing when initializing ;)

(for instance, an NHibernate session factory takes long).

Ernst Kuschke

Kuschke Consulting
www.kuschkeconsulting.com
083 979-1760

Sent from my iPhone

On 17 Feb 2011, at 17:47, Serhat Özgel <serhatozgel@...> wrote:

> We are using Castle Windsor. A fraction of this time may be taken by initializing nhibernate session or configuration facilities so I may have been wrong taking initialization time into consideration. My main issue is, we have too much dependencies that I am starting to think we are doing something wrong.
>
>
> On Thu, Feb 17, 2011 at 5:44 PM, Steven Smith <ssmith.lists@...> wrote:
>  
> What IOC container are you using that takes 10 seconds to wire up 1000 types on startup?
>
> Steve
>
>
>
>
> On Wed, Feb 16, 2011 at 5:36 PM, Serhat Özgel <serhatozgel@...> wrote:
>  
> In my case, we have a web app that has lots of modules. A business layer class has 5-6 dependencies on the average. We try to follow solid strictly, not perfect but almost there. The problem is, we have hundreds of classes that we register into our ioc container and it is growing. The registrations alone take nearly 10 seconds on app init. How would you deal with such a situation? Is it ok to have  hundreds or thousands of registrations in an app?
>
>
>
> On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:
>  
> I'm saying, once you unit test / integration test properly, you'll discover the parts that are too sticky. It'll force you into more modular design, and then you'll see how the modules grow apart.
> These modules will depend upon each other in various ways, and it'll be the DI's job to inject the dependencies.
>
>
> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...> wrote:
>  
> > unit/integration testing will show you the sweet spot
> >
> So are you saying that I should really only be using DI as seams for  tests?
>
>
>
>
>
>
> --
> Steve Smith
> http://SteveSmithBlog.com/
> http://twitter.com/ardalis
>
>
>

[Ryan Roberts]

Looks like you need some conventions


public class ServiceInstaller : IWindsorInstaller
{
      public void Install(IWindsorContainer container, IConfigurationStore
store)
      {

container.Register(ImplementationsInNamespaceEndingWith("Services"));
      }

        static BasedOnDescriptor ImplementationsInNamespaceEndingWith(string
ns)
        {
            return AllTypes.FromThisAssembly()
                .Pick()
                .If(t => t.Namespace != null && t.Namespace.EndsWith(ns))
                .Configure(c => c.LifeStyle.HybridPerWebRequestTransient())
                .WithService.AllInterfaces()
                .WithService.Self();
        }
}

public class ControllerInstaller : IWindsorInstaller
{
   public class ControllerInstaller : IWindsorInstaller
    {
        public void Install(IWindsorContainer container, IConfigurationStore
store)
        {
           container.Register(AllTypes.FromThisAssembly()
                .Pick()
                .If(t => typeof(Controller).IsAssignableFrom(t))
                .Configure(c => c.LifeStyle.HybridPerWebRequestTransient())
                .WithService.Self());
        }
   }
}

HybridPerWebRequestTransient is in the contrib windsor lifestyles project,
very handy for being able to test your container registrations.

Ryan




On Thu, Feb 17, 2011 at 4:22 PM, Serhat Özgel <serhatozgel@...> wrote:

>
>
> It is less or more like this:
>
> Controllers are mvc controllers, which get data from client, converts it
> into dtos and passes to services. Repositories generally contain unique
> methods to that domain. A common repository is used for common stuff like
> simple selects, crud, etc. Business logic goes to services and services
> already contain lots of code so  it would not be a good idea to reduce their
> numbers (we must do the opposite).
>
>
> _container.Register(Component.For<IKController>().ImplementedBy<KController>().LifeStyle.Transient);
>
> _container.Register(Component.For<IYController>().ImplementedBy<YController>().LifeStyle.Transient);
>
> _container.Register(Component.For<IZController>().ImplementedBy<ZController>().LifeStyle.Transient);
> (goes on for 100 lines)
> ...
>
> _container.Register(Component.For<IKService>().ImplementedBy<KService>().LifeStyle.Transient);
>
> _container.Register(Component.For<ILService>().ImplementedBy<LService>().LifeStyle.Transient);
>
> _container.Register(Component.For<IMService>().ImplementedBy<MService>().LifeStyle.Transient);
> (goes on for 300 lines)
> ...
>
> _container.Register(Component.For<IDomainXRepository>().ImplementedBy<XDomainRepository>().LifeStyle.Transient);
>
> _container.Register(Component.For<IDomainYRepository>().ImplementedBy<YDomainRepository>().LifeStyle.Transient);
>
> _container.Register(Component.For<IDomainZRepository>().ImplementedBy<ZDomainRepository>().LifeStyle.Transient);
> (goes on for 200 lines)
> ...
>
> _container.Register(Component.For<IEncryptor>().ImplementedBy<BcryptEncryptor>());
>
> ._container.Register(Component.For<IJsonSerializer>().ImplementedBy<Serialization.Impl.JsonSerializer>());
>
> _container.Register(Component.For<IResourceReader>().ImplementedBy<ResourceReader>());
>
> _container.Register(Component.For<IXmlSerializer>().ImplementedBy<XmlSerializer>());
>
> _container.Register(Component.For<IUnitOfWorkFactory>().ImplementedBy<UnitOfWorkFactory>().LifeStyle.Transient);
> (goes on for 50 lines for utility stuff)
> ...
> [registrations for other stuff like imports, web services, etc.]
> (goes on for 50 lines)
> ...
>
> On Thu, Feb 17, 2011 at 5:52 PM, Steven Smith <ssmith.lists@...>wrote:
>
>>
>>
>> Maybe you are doing something wrong, maybe not.  I don't know that we on
>> the list have enough information to guide you one way or the other.  Can you
>> share a particular example that concerns you?
>>
>>
>> On Thu, Feb 17, 2011 at 10:47 AM, Serhat Özgel <serhatozgel@...>wrote:
>>
>>>
>>>
>>> We are using Castle Windsor. A fraction of this time may be taken by
>>> initializing nhibernate session or configuration facilities so I may have
>>> been wrong taking initialization time into consideration. My main issue is,
>>> we have too much dependencies that I am starting to think we are doing
>>> something wrong.
>>>
>>> On Thu, Feb 17, 2011 at 5:44 PM, Steven Smith <ssmith.lists@...>wrote:
>>>
>>>>
>>>>
>>>> What IOC container are you using that takes 10 seconds to wire up 1000
>>>> types on startup?
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>> On Wed, Feb 16, 2011 at 5:36 PM, Serhat Özgel <serhatozgel@...>wrote:
>>>>
>>>>>
>>>>>
>>>>> In my case, we have a web app that has lots of modules. A business
>>>>> layer class has 5-6 dependencies on the average. We try to follow solid
>>>>> strictly, not perfect but almost there. The problem is, we have hundreds of
>>>>> classes that we register into our ioc container and it is growing. The
>>>>> registrations alone take nearly 10 seconds on app init. How would you deal
>>>>> with such a situation? Is it ok to have  hundreds or thousands of
>>>>> registrations in an app?
>>>>>
>>>>>
>>>>> On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> I'm saying, once you unit test / integration test properly, you'll
>>>>>> discover the parts that are too sticky. It'll force you into more modular
>>>>>> design, and then you'll see how the modules grow apart.
>>>>>> These modules will depend upon each other in various ways, and it'll
>>>>>> be the DI's job to inject the dependencies.
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > unit/integration testing will show you the sweet spot
>>>>>>> >
>>>>>>> So are you saying that I should really only be using DI as seams for
>>>>>>> tests?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Steve Smith
>>>> http://SteveSmithBlog.com/
>>>> http://twitter.com/ardalis
>>>>
>>>>
>>>
>>
>>
>> --
>> Steve Smith
>> http://SteveSmithBlog.com/
>> http://twitter.com/ardalis
>>
>>
>  
>

[Mario Pareja]

It looks like you need to take advantage of convention based registration
here.

Mario

On Thu, Feb 17, 2011 at 11:22 AM, Serhat Özgel <serhatozgel@...>wrote:

>
>
> It is less or more like this:
>
> Controllers are mvc controllers, which get data from client, converts it
> into dtos and passes to services. Repositories generally contain unique
> methods to that domain. A common repository is used for common stuff like
> simple selects, crud, etc. Business logic goes to services and services
> already contain lots of code so  it would not be a good idea to reduce their
> numbers (we must do the opposite).
>
>
> _container.Register(Component.For<IKController>().ImplementedBy<KController>().LifeStyle.Transient);
>
> _container.Register(Component.For<IYController>().ImplementedBy<YController>().LifeStyle.Transient);
>
> _container.Register(Component.For<IZController>().ImplementedBy<ZController>().LifeStyle.Transient);
> (goes on for 100 lines)
> ...
>
> _container.Register(Component.For<IKService>().ImplementedBy<KService>().LifeStyle.Transient);
>
> _container.Register(Component.For<ILService>().ImplementedBy<LService>().LifeStyle.Transient);
>
> _container.Register(Component.For<IMService>().ImplementedBy<MService>().LifeStyle.Transient);
> (goes on for 300 lines)
> ...
>
> _container.Register(Component.For<IDomainXRepository>().ImplementedBy<XDomainRepository>().LifeStyle.Transient);
>
> _container.Register(Component.For<IDomainYRepository>().ImplementedBy<YDomainRepository>().LifeStyle.Transient);
>
> _container.Register(Component.For<IDomainZRepository>().ImplementedBy<ZDomainRepository>().LifeStyle.Transient);
> (goes on for 200 lines)
> ...
>
> _container.Register(Component.For<IEncryptor>().ImplementedBy<BcryptEncryptor>());
>
> ._container.Register(Component.For<IJsonSerializer>().ImplementedBy<Serialization.Impl.JsonSerializer>());
>
> _container.Register(Component.For<IResourceReader>().ImplementedBy<ResourceReader>());
>
> _container.Register(Component.For<IXmlSerializer>().ImplementedBy<XmlSerializer>());
>
> _container.Register(Component.For<IUnitOfWorkFactory>().ImplementedBy<UnitOfWorkFactory>().LifeStyle.Transient);
> (goes on for 50 lines for utility stuff)
> ...
> [registrations for other stuff like imports, web services, etc.]
> (goes on for 50 lines)
> ...
>
> On Thu, Feb 17, 2011 at 5:52 PM, Steven Smith <ssmith.lists@...>wrote:
>
>>
>>
>> Maybe you are doing something wrong, maybe not.  I don't know that we on
>> the list have enough information to guide you one way or the other.  Can you
>> share a particular example that concerns you?
>>
>>
>> On Thu, Feb 17, 2011 at 10:47 AM, Serhat Özgel <serhatozgel@...>wrote:
>>
>>>
>>>
>>> We are using Castle Windsor. A fraction of this time may be taken by
>>> initializing nhibernate session or configuration facilities so I may have
>>> been wrong taking initialization time into consideration. My main issue is,
>>> we have too much dependencies that I am starting to think we are doing
>>> something wrong.
>>>
>>> On Thu, Feb 17, 2011 at 5:44 PM, Steven Smith <ssmith.lists@...>wrote:
>>>
>>>>
>>>>
>>>> What IOC container are you using that takes 10 seconds to wire up 1000
>>>> types on startup?
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>> On Wed, Feb 16, 2011 at 5:36 PM, Serhat Özgel <serhatozgel@...>wrote:
>>>>
>>>>>
>>>>>
>>>>> In my case, we have a web app that has lots of modules. A business
>>>>> layer class has 5-6 dependencies on the average. We try to follow solid
>>>>> strictly, not perfect but almost there. The problem is, we have hundreds of
>>>>> classes that we register into our ioc container and it is growing. The
>>>>> registrations alone take nearly 10 seconds on app init. How would you deal
>>>>> with such a situation? Is it ok to have  hundreds or thousands of
>>>>> registrations in an app?
>>>>>
>>>>>
>>>>> On Wed, Feb 16, 2011 at 11:15 PM, Dotan N. <dipidi@...> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> I'm saying, once you unit test / integration test properly, you'll
>>>>>> discover the parts that are too sticky. It'll force you into more modular
>>>>>> design, and then you'll see how the modules grow apart.
>>>>>> These modules will depend upon each other in various ways, and it'll
>>>>>> be the DI's job to inject the dependencies.
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 16, 2011 at 11:12 PM, kogerbnz <kogerbnz@...>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > unit/integration testing will show you the sweet spot
>>>>>>> >
>>>>>>> So are you saying that I should really only be using DI as seams for
>>>>>>> tests?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Steve Smith
>>>> http://SteveSmithBlog.com/
>>>> http://twitter.com/ardalis
>>>>
>>>>
>>>
>>
>>
>> --
>> Steve Smith
>> http://SteveSmithBlog.com/
>> http://twitter.com/ardalis
>>
>>
>  
>

[Derek Greer]

In addition to Ryan's suggestion to replace your explicit registration with
a convention-based approach, it also appears that you've created interfaces
for each of your controllers.  This shouldn't be necessary, as I doubt you
have anything consuming these interfaces.

Derek

[Serhat Özgel]

Using conventions seems like the right idea, I'll definitely look into it.
Controllers do not have interfaces actually but we still need to register
them. So, If I'm understanding this correctly, having this much dependencies
is not a bad practice as long as I do not register the dependencies
manually.

On Thu, Feb 17, 2011 at 8:19 PM, Derek Greer <dbgreer@...> wrote:

>
>
> In addition to Ryan's suggestion to replace your explicit registration with
> a convention-based approach, it also appears that you've created interfaces
> for each of your controllers.  This shouldn't be necessary, as I doubt you
> have anything consuming these interfaces.
>
> Derek
>
>  
>

[bill barry]

I am not convinced that registering them via conventions is at all
faster than doing so manually (it does however make for easier to check
code).  I also have many many classes in my container (each one of 35+
[depending on which app] assemblies registers anywhere from a dozen to
several hundred components; we have been using Windsor for a few years
now and have built up quite the collection of components).

One thing that would likely be faster is to serialize the initialized
form of the container and then deserialize it in future startups. I am
not sure if this can be done with Windsor, but doing the same thing
essentially with NHibernate considerably improved our app startup times.

On 2/17/2011 2:39 PM, Serhat Özgel wrote:
>
>
> Using conventions seems like the right idea, I'll definitely look into
> it. Controllers do not have interfaces actually but we still need to
> register them. So, If I'm understanding this correctly, having this
> much dependencies is not a bad practice as long as I do not register
> the dependencies manually.

[Derek Greer]

I'm fairly certain everyone's recommendations to use convention-based registration was a response to discovering Serhat was still explicitly registering everything, not a solution for reducing startup time. I was curious about exactly what he was doing in case there were issues of the same assemblies being scanned more than once.


On Feb 17, 2011, at 5:47 PM, Bill Barry <after.fallout@...> wrote:

> I am not convinced that registering them via conventions is at all faster than doing so manually (it does however make for easier to check code).  I also have many many classes in my container (each one of 35+ [depending on which app] assemblies registers anywhere from a dozen to several hundred components; we have been using Windsor for a few years now and have built up quite the collection of components).
>
> One thing that would likely be faster is to serialize the initialized form of the container and then deserialize it in future startups. I am not sure if this can be done with Windsor, but doing the same thing essentially with NHibernate considerably improved our app startup times.
>
> On 2/17/2011 2:39 PM, Serhat Özgel wrote:
>
>> Using conventions seems like the right idea, I'll definitely look into it. Controllers do not have interfaces actually but we still need to register them. So, If I'm understanding this correctly, having this much dependencies is not a bad practice as long as I do not register the dependencies manually.
>
>

[Ryan Roberts]

The conventions were for your sanity rather than performance, if anything
they will make it a little slower what with all the reflection.

Are you doing any significant work in any of your constructors? Especially
for a component that is transient? Ideally you should only take on
dependencies and setup safe default state.

Ruan

On Fri, Feb 18, 2011 at 1:22 AM, Derek Greer <dbgreer@...> wrote:

>
>
> I'm fairly certain everyone's recommendations to use convention-based
> registration was a response to discovering Serhat was still explicitly
> registering everything, not a solution for reducing startup time. I was
> curious about exactly what he was doing in case there were issues of the
> same assemblies being scanned more than once.
>
>
> On Feb 17, 2011, at 5:47 PM, Bill Barry <after.fallout@...> wrote:
>
>
>
> I am not convinced that registering them via conventions is at all faster
> than doing so manually (it does however make for easier to check code).  I
> also have many many classes in my container (each one of 35+ [depending on
> which app] assemblies registers anywhere from a dozen to several hundred
> components; we have been using Windsor for a few years now and have built up
> quite the collection of components).
>
> One thing that would likely be faster is to serialize the initialized form
> of the container and then deserialize it in future startups. I am not sure
> if this can be done with Windsor, but doing the same thing essentially with
> NHibernate considerably improved our app startup times.
>
> On 2/17/2011 2:39 PM, Serhat Özgel wrote:
>
> Using conventions seems like the right idea, I'll definitely look into it.
> Controllers do not have interfaces actually but we still need to register
> them. So, If I'm understanding this correctly, having this much dependencies
> is not a bad practice as long as I do not register the dependencies
> manually.
>
>
>  
>

[Juanma-9]

Regarding perfomance, take a look at OptimizeDependencyResolution() in
IKernel. It solves some performance problems with Windsor.

If you are using an older version of Windsor and can't update, you can
reduce startup time registering your components from "less to more
dependant", i.e., first the components that don't have external
dependencies, then components that depend upon them, and so on.

On Fri, Feb 18, 2011 at 2:40 AM, Ryan Roberts <ryansroberts@...>wrote:

>
>
> The conventions were for your sanity rather than performance, if anything
> they will make it a little slower what with all the reflection.
>
> Are you doing any significant work in any of your constructors? Especially
> for a component that is transient? Ideally you should only take on
> dependencies and setup safe default state.
>
> Ruan
>
>
> On Fri, Feb 18, 2011 at 1:22 AM, Derek Greer <dbgreer@...> wrote:
>
>>
>>
>> I'm fairly certain everyone's recommendations to use convention-based
>> registration was a response to discovering Serhat was still explicitly
>> registering everything, not a solution for reducing startup time. I was
>> curious about exactly what he was doing in case there were issues of the
>> same assemblies being scanned more than once.
>>
>>
>> On Feb 17, 2011, at 5:47 PM, Bill Barry <after.fallout@...> wrote:
>>
>>
>>
>> I am not convinced that registering them via conventions is at all faster
>> than doing so manually (it does however make for easier to check code).  I
>> also have many many classes in my container (each one of 35+ [depending on
>> which app] assemblies registers anywhere from a dozen to several hundred
>> components; we have been using Windsor for a few years now and have built up
>> quite the collection of components).
>>
>> One thing that would likely be faster is to serialize the initialized form
>> of the container and then deserialize it in future startups. I am not sure
>> if this can be done with Windsor, but doing the same thing essentially with
>> NHibernate considerably improved our app startup times.
>>
>> On 2/17/2011 2:39 PM, Serhat Özgel wrote:
>>
>> Using conventions seems like the right idea, I'll definitely look into it.
>> Controllers do not have interfaces actually but we still need to register
>> them. So, If I'm understanding this correctly, having this much dependencies
>> is not a bad practice as long as I do not register the dependencies
>> manually.
>>
>>
>>
>  
>