Re: WebObjects and dependency injection (DI)
Re: WebObjects and dependency injection (DI)
- Subject: Re: WebObjects and dependency injection (DI)
- From: Henrique Prange <email@hidden>
- Date: Mon, 21 Sep 2009 19:12:58 -0300
Hi Anjo,
Anjo Krank wrote:
Just so I know: does DI make anything simpler aside from unit testing?
Is it worth the cost of un-readbility and un-debugablity? I mean, for
foreign code i totally rely on eclipse call graphs... these are a
nightmare with interfaces, not to mention missing constructors.
You can produce detailed object graph description using Guice Grapher
extension (of course, you must use Guice as a DI container). I've never
tried it, but it seems to work.
There is also a Guice plug-in for Eclipse that promises to help in this
direction.
Cheers,
Henrique
Cheers, Anjo
Am 21.09.2009 um 21:17 schrieb Andrus Adamchik:
Hi Henrique,
Nice, thanks for sharing this info. Yeah, going through WOApplication
and WOComponentDefinition, I realized I was too optimistic. Most
interesting methods that would've enabled DI integration are all
private. Quite a bit of code to rewrite to make it work. I was even
thinking of limiting injection to just the Application class.
Great that you are willing to open source your work in this area. Even
if you load your code in its current state to a public SVN
(ObjectStyle.org is always an option) or git somewhere, it will be a
rather helpful example.
Cheers,
Andrus
---------------------------------------------
Andrus Adamchik
Apache Cayenne ORM: http://cayenne.apache.org/
Creator of Cayenne, VP Apache Software Foundation
On Sep 21, 2009, at 6:18 PM, Henrique Prange wrote:
Hi Andrus,
Andrus Adamchik wrote:
I know it is not the traditional "WO way" of doing things, but from
my experience using a dependency injection container in your app
(Spring, Guice, etc.) is one single thing that you can do to
dramatically improve the design quality, and produce flexible and
maintainable code.
We have been using Guice with WO for some time in our projects. Our
code become easier to test without requiring too much boilerplate
code using a DI container.
WO does a bit of that on its own (such as session and application
injection in components), but doesn't bundle a container that a
developer could use for the custom "services" (unlike say Tapestry,
that does have a DI container at its core).
Say I have a WO application and I'd like to use Spring or Guice to
inject custom services in the WOComponents, instead of looking them
up in WOApplication (or worse - defining them as static singletons
somewhere). This sounds easy on the surface. I don't remember all
the component creation internals now (it's been a while since I
poked around the framework code), but I am pretty sure I can create
them with my own factory that is DI container aware. On the other
hand (also because I've been out of the loop on WO for quite some
time), I am sure I am missing some pieces of the puzzle that would
make such setup less practical or outright painful.
Instead of changing component creation internals, we've created an
extension of ERXComponent that obtain the injector and inject the
required members. It is not a perfect solution (you can't use
constructor injection this way), but it is easy to implement.
This and the fact that DI capabilities don't seem to bother the rest
of the community, I figured I'd ask the list on your opinions, while
I am trying to wire this thing up in the background.
So anybody played with DI-on-WO in some form with any success?
We have an audit framework completely based on Guice. We have created
extensions of other important classes to make it possible, like
ERXGenericRecord and ERXEC and we have created a @WOSessionScoped
scope to create/obtain objects per WOSession.
We are planning to create an open source framework with this stuff.
We are just polishing what we've done to use some new features of
Guice 2.0.
Cheers,
Henrique
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden