ioc in C++
findev
work with and modify Vs write my own IOC framework. My requirement is
in C++ and very sensitive to latency, but at the same time I dont want
to write something I dont have to.
My questions are :
1) My understanding is that every call from one bean to another or
container to bean has to go through a proxy which is inherently a
search on all the id's i have in my setup.xml. If this is true, I
will incur a search (however small it be). Given this, is there any
provision to write my own hash code to optimize with my custom naming.
2) I would prefer to avoid the reflection and use an interface to
achieve loose coupling and even add some DI
3) It appears that autumn is closer to what I have in mind. Any
views on autumn vs poco ? Any perf benchmarks. I saw one for .net
called IoCBenchmark but none for C++.
4) It doesnt look hard to write my own IOC. Is there any advantage
to using the frameworks esp because they could be written better in my
opinion ? Esp because the I am mainly interested in loose coupling.
Thanks all !
Ke Jin
On Feb 26, 8:23 pm, findev <find...@gmail.com> wrote:
> Would like to get an opinion on how poco, autumn are as frameworks to
> work with and modify Vs write my own IOC framework. My requirement is
> in C++ and very sensitive to latency, but at the same time I dont want
> to write something I dont have to.
>
> My questions are :
>
> 1) My understanding is that every call from one bean to another or
> container to bean has to go through a proxy which is inherently a
> search on all the id's i have in my setup.xml. If this is true, I
> will incur a search (however small it be). Given this, is there any
> provision to write my own hash code to optimize with my custom naming.
Wrong. In general, bean-to-bean invocations do not go through IoC
container, neither such invocations need to go through proxies.
Specific to PocoCapsule, the overhead of bean-to -bean invocations
added by the IoC container (i.e. PocoCapsule) is exactly ZERO.
Sound like you are looking for a framework that intercepting bean-to-
bean invocations? IoC container isn't for that purpose. Even through
some IoC container come with AOP that can serve for that intercepting
purpose, it is a feature orthogonal to IoC.
>
> 2) I would prefer to avoid the reflection and use an interface to
> achieve loose coupling and even add some DI
Wrong again. The purpose of IoC/DI used by IoC container is orthogonal
to the purpose of reducing bean-to-bean coupling. Instead, applying
IoC in IoC container is to eliminate bean-to-component coupling. These
bean-to-container coupling appears in two cases:
a) beans have to call container specific factory (i.e. service-lookup)
to resolve their inter-dependency.
b) beans have to support container specific interface(s) to be
manipulated by the container.
Predefining a container specific interface to be supported by
component immediately violates the non-invasive premise of IoC
containers and prohibits the container agnostic components.
>
> 3) It appears that autumn is closer to what I have in mind. Any
> views on autumn vs poco ? Any perf benchmarks. I saw one for .net
> called IoCBenchmark but none for C++.
Wrong again. As said, decent IoC containers should introduce ZERO
overhead to bean-to-bean invocations (unless you were using the
orthogonal AOP feature which would have overhead anyway even without
IoC). Those benchmarks are completely nonsense and misleading.
>
> 4) It doesnt look hard to write my own IOC.
Reinvent wheel is always easy.
> Is there any advantage
> to using the frameworks esp because they could be written better in my
> opinion ? Esp because the I am mainly interested in loose coupling.
>
Two very common misunderstanding on IoC containers are:
1. IoC containers are to facilitate the IoC/DI design pattern.
2. The purpose of these design pattern is to have loose bean-to-bean
coupling.
First, it is not IoC containers to enable/help IoC/DI design, but is
this design used/helped these containers. This is just like service-
lookup containers (e.g. old EJB) were not to support/help service-
lookup design pattern (you can use a hash table for this purpose), but
they (these service-lookup containers) used/helped by this design.
Another similiar example is that Hadoop is not to support the Lisp/
Python'ish MapReduce programming pattern, but simply used this
pattern. You certainly do NOT need (and even should NOT use) a
framework if you want to apply IoC/DI, service-lookup, MapReduce etc
design patterns in your code, but you do need use the features of
these frameworks that are actually orthogonal to the programming
design pattern (even if they are named with these pattern).
Second, as said previously, IoC/DI design isn't to reduce bean-to-bean
coupling, but to eliminate bean-to-container coupling (i.e. hardcode
to call container's bean factories, and hardcode to support container
predefined bean interface(s)). In fact, IoC/DI containers actually
increased (rather than reduced) bean-to-bean "lifecycle" couplings
comparing to service-lookup containers.
Hope this post helps!
Ke
> Thanks all !