Re: WebObjects and dependency injection (DI)
Re: WebObjects and dependency injection (DI)
- Subject: Re: WebObjects and dependency injection (DI)
- From: Andrus Adamchik <email@hidden>
- Date: Mon, 21 Sep 2009 23:46:37 +0300
Personally I don't even care that much about unit testing web
applications. In data-driven apps, even with DI, it is hard to create
good mock data for most of your services, as it may depend on a pretty
deep object graph.
To me DI is all about clean design and decoupling of functionality
from configuration. Implementing core application services as
interfaces is one part of it (not really dependent on DI), but DI
serves as a glue for those services. At the end it gives you
flexibility to tweak things by swapping implementations of services
without touching the components or writing endless if/else manual
configuration code.
One real-life example is a CMS system that would generate vhost based
URLs when in production (http://vhost.example.org) and path-based URLs
in development environment with no DNS capability (http://localhost/vhost
).
Another one from the CMS realm is a cache service that is implemented
differently depending on whether the same application is in live mode
vs. preview mode, allowing for instantaneous page refreshing in
preview mode and best performance on a live site.
Then there's all the interceptors that you can build around interface
method calls. I don't use it too often personally, but on a rare
occasion when you need it, this is priceless.
To be sure all of that can be achieved without DI. DI just makes it
declarative and cleaner, and actually encourages you to follow this
specific development pattern.
Andrus
On Sep 21, 2009, at 11:22 PM, 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.
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:
@krank.net
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