LightWire Version 0.01 released!

I've just upgraded LightWire (from version 0.001) to support proper constructor, setter and (the newly defined) mixin injection methods. It handles circular dependencies in all three (or any combination of them), provides lazy loading and has a very simple to use programmatic config file. It is also optimized to inject dependencies into transients as well as singletons and at under 300 lines of code, there is only so much that can go wrong :->

If you’re looking to better understand how Dependency Injection/Inversion of Control works, at under three hundred lines of code it makes perfect sense to at least check out LightWire to see one way to implement a simple DI engine. If you’re just looking for a DI engine off the shelf to solve a problem, I‘ve outlined some of the strengths of LightWire as well as the outstanding priority enhancements and outstanding issues that are less of a priority to give a sense of the current state of play of the LightWire experiment.

Current Features Base class path – Instead of having to enter the full class path for every bean, you can create a single base class path to prepend all bean class paths with. This makes it easier to reuse configuration information between different applications with different mappings as only one property needs to be changed – not one per bean.
Programmatic configuration file – If you have multiple similar configurations, you can use the full power of a programming language to programmatically set those configuration properties. You still have the ability to use multiple config files, but you don’t have to have multiple config files where a few if statements will do the same job without you having to repeat changes (such as additions of new bean definitions) in multiple files.
Mixin Injection - Mixin injection provides the benefits of setter injection (supporting the resolution of circular dependencies) without “messing up” your bean APIs by requiring set%ObjectName%() methods for injecting the objects. LightWire still supports constructor injection (recommended) and setter injection (where you need it).

Priority Improvements AOP - I consider AOP as an essential feature for a DI engine and will be adding an implementation within the month. It will be based on the Spring approach, but simplified where possible.
Custom bean factories - LightWire is already optimized for creating transients, and I want to make it session aware a la Spring 2.0. I want to provide a range of value added features to any custom bean factory support, but I’m not sure exactly how to implement this. Expect custom bean factory support some time this year as soon as I can figure out the most valuable way to implement them. Any thoughts on approaches or features seriously appreciated.

Outstanding Issues
These are items I could address but that aren’t a priority for my use case, so they won’t get added until there is a demand for them. If you like LightWire but any of these are a deal killer for you, drop me a line and let me know!
XML Config - I honestly prefer the flexibility of a programmatic configuration file, but might add support for a subset of the Spring DTD if it made sense to do so.
Auto wiring - I really don’t like autowiring. I’m concerned with transients that there is a real possibility of naming conflicts in larger projects (properties which have the same name as a bean and get the bean setter injected by accident). I also really like my LightWire config file to tell me what beans depend on what other ones as that is extremely useful information. Because of this it is extremely unlikely that LightWire will ever support autowiring. On the upside, the extra work of mentioning the bean dependencies is mitigated by the fact that you just have to provide a comma delimited list, not a bunch of XML, and if you use mixin instead of setter injection you can get rid of a bunch of setter methods which would otherwise be messing up the API of those beans, so I’m thinking on balance the amount of typing comes out about even and I feel that the LightWire approach gives you a much clearer picture of your application as the config file fully describes all dependencies. I’m always open to persuasion, but am less open on autowiring than on most other things.

Of course LightWire is very early stage, so I wouldn’t use it on a production project just yet and there isn’t much in the way of a support group or community. Documentation is also very sparse, but if anyone finds this to be of any use, let me know and I can work up some more docs and other resources!

Aaron Roberson's Gravatar Peter,

I have a questions about your implementation.

First, can I use LightWire with a more service layer oriented architecture even though you recommend putting more behavior into the business objects? Are we boxed here?

Secondly, why do you recommend constructor injection instead of setter injection? Kurt Weirsma emphasized at the Frameworks Conference that it is better to use setter injection. I can see that using a setter method would make the injected object available to all of the methods in the class, rather than having to inject them into each methods constructor.
# Posted By Aaron Roberson | 2/7/07 4:13 PM
Peter Bell's Gravatar Hi Aaron,

The difference with LightWire is that you have the *option* of injecting into transients. I would imagine the vast majority of the time you'll be injecting into service layers (I do), so that is fine. You're not limited to one approach, but are rather given both.

If you Google Martin Fowler and Dependency Injeciton, you'll find a huge thing he wrote that covers constructor vs setter injection. LW supports both equally. Firstly, there is no difference between setter and constructor injection in terms of where the objects are available - either approach does exactly the same - putting (say) UserDAO into the private variables scope of UserService so either way allows equal access to the objects from the methods in the class. The difference between the two is pretty subtle and for now I'd say don't worry about it other than if you have circular dependencies (e.g. CompanyService depends on UserService and UserService also depends on CompanyServie) you MUST use setter injection fr those. Just to spice things up I've also added mixin injection to save you a bunch of typing and still give you a setter injection style solution. Search my blog and you'll see more about that!
# Posted By Peter Bell | 2/7/07 4:23 PM
Guojuicycoutureout's Gravatar :// coach factory outlet
:// coach outlet online
:// coach outlet
:// coach outlet online
:// juicy couture outlet online
:// Coach outlet store online
:// Coach outlet online
:// coach outlet store online
# Posted By Guojuicycoutureout | 11/27/11 10:21 PM
The Beats Headphones's Gravatar <a href="://">Beats headphones on sale</a><br>
<a href="://"> Beats headphones cheap</a><br>
<a href="://">beats headphones tour</a><br>

<a href="://">Beats Studio By Dr. Dre</a><br>
<a href="://">Best Studio Headphones</a><br>
<a href="://">Studio Headphones Reviews</a><br>

<a href="://">dr dre beats review</a><br>
<a href="://">dr dre beats cheap</a><br>
<a href="://">dr dre beats outlet</a><br>

<a href="://">dr dre beats online shop</a><br>
<a href="://">dr dre beats cheap</a><br>
<a href="://">dr dre beats wholesale</a><br> ykwyy-clj1228
# Posted By The Beats Headphones | 12/27/11 6:13 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress