By Peter Bell

LightWire: Why I Love Mixin Injections

I guess seeing Paul playing with LightWire has got me on a roll here. Recently I've been completely overloaded with getting a bunch of major projects out the door, but I wanted to invest one subway ride in getting some postings out about why LightWire is really working for me. I have about three more stops :->

One thing I do want to clear up. LightWire isn't for everyone. I think it is best for more experienced developers working in smaller teams with their peers. It provides a lot of power and (like Ruby) makes it easier to make bad choices. That said, I'm finding that it allows me to ship maintainable code more quickly than anything else I've played with so I'm going to mention what I love about it and what's working for me. Your mileage may vary. If it doesn't work for you, I'm sure you could find something else!

So, about mixin injection (want less typing AND a better API?!) . . .

I like constructor injection. To me it documents a clear contract concerning the dependencies that a bean has and needs to be fully constructed and usable. Unfortunately, you can't resolve circular dependencies in constructor injection, so setter injection was born.

The issue I have with setter injection is that there in no distinction between things you are supposed to set in your code and setters that are reserved for the DI engine. Because of that I feel that setter injection is really an anti-pattern. However, given that it is (a) endorsed by most of the top OO thinkers, and (b) the only game in town for resolving circular dependencies, I'm either ahead of my time or missing something :->

Nothing I can do about (a) (although I'll be attending OOPSLA this year so I'll try to buttonhole some of the top thinkers and change their minds :->) but (b) is a whole other thing. In LightWire we have a third type of injection called Mixin injection. It also solves the problem of circular dependencies by doing the same thing a setter injection, but it uses a single generic mixin method that gets tagged onto every bean generated by LightWire. In this way, rather than having t write hundreds of setter methods for your bens DI requirements (or resorting to hacks like Joe suggested to mix in a cfm with abunch of common setter methods into a bunch of your cfcs) you just describe dependencies in your bean config and it mixin injects them for you automatically.

So, the central config file becomes your authoritative reference of dependencies, the API of your beans becomes much cleaner and less misleading and you save a *bunch* of typing. What's NOT to love?

OK, and that's my station, so back to the regularly scheduled silence so I can get a shopping cart, support for parameterization of custom data types and a data grid component with filtering, paging and ordering done before I go to bed tonight. Adios!

Comments
BlogCFC was created by Raymond Camden. This blog is running version 5.005.