> -----Original Message----- > From: Hamilton Verissimo de Oliveira (Engenharia - SPO) > > > > while at the same time coupling your application code to the underlying > framework > > Yes, its true. But if one bought the idea of using Avalon he/she must keep > this in mind. > > The biggest downsize of avalon approach - to me - is to reuse avalon > components in some scenarios that won't benefit from Avalon Framework. > Hence > my suggestion of supporting more that one IoC level (aaaghh) in Avalon# > and > maybe in others.
First off, the more I've read Stefano and other's comments, the more I agree that the term IoC is currently being misused. IoC, like Seperation of Concerns, is a principle more than an actual pattern. Dependency Injection is a pattern, but IoC (and Avalon) is more than just dependency management. Anyway, you brought up two good points: 1. Support of other dependency management schemes in Avalon 2. Making it easier to reuse Avalon components in non-Avalon frameworks You should definitely add support for multiple schemes in Avalon#. We've already started discussing how to do this in Merlin and I believe we'll get it in there soon. As for #2, I've found when I've tried to reuse component implementations that inevitably I end up writing a small container -- something that creates the configuration, goes through the lifecycles, figures out dependencies... In the end, it's often just easier to use a small container (or something like my JingDAO framework). This was part of the idea of Fortress and I think it still has merit -- some minimal container that requires adding only one or two jars to your classpath. J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
