Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion
|
From: Kevin D. <ke...@tr...> - 2008-07-07 17:29:54
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>thanks for the explanation on where the service locator pattern came from - that helps a lot. I'm wondering if there may be value in trying to capture the true complexity of the dependency graph that's involved and see what sorts of things maybe could benefit from refactoring, injection by convention perhaps - it sounds like there has been a lot of movement in the Spring web framework to simplify this kind of declarative injection.</DIV>
<DIV> </DIV>
<DIV>I certainly want to minimize the amount of boiler plate/explicit configuration required for consumers of the framework. The configuration-by-convention approach that some web frameworks are beginning to use is quite appealing.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Larry Streepy <A href="mailto:lst...@au..."><FONT color=#0000ff><lst...@au...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Mon, 07 Jul 2008 11:45:49 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion</U></B></DIV>
<DIV> </DIV></DIV><TT>Hi Everyone,<BR><BR>It's been a long time since I've participated, so hopefully my viewpoints won't be too dated :-)<BR><BR>IOn the issue of OSGi, I would argue along the lines of Jim Moore - do it later when we find a pressing need that can't be solved without it, and work to cleanly modularize our codebase to ensure no cyclic dependencies etc.<BR><BR>To Kevin's question about the decision to not use DI for the core services (and to use a service locator pattern instead), the main reason that it came about was due to the massive amount of XML that would be required to inject the desired services into every object. Additionally, the number of dynamic objects that need access to platform services can be huge, and there was no good way to get the quickly wired in. You either had to resort to intermediate factories that could be DI'd and have the factories wire in the services (and that required extra interfaces on the created objects
to accept the injection), or invent some other similar scenario to get the services into the dynamic objects.<BR><BR>I'm still of the opinion that a service locator singleton (with a pluggable implementation) provides benefits and doesn't require the complexity of having to have a declarative model that knows about every single kind of object that might come into existence during the life of the application. But, I'm always ready to be educated out of any antiquated notions I may hold if someone can show me how the wiring of dynamic objects can be handled in a simple way (very little XML and minimal biolerplate).<BR><BR>Learning curve and the amount of XML you have to write in order to get your application running were two significant factors we faced with the adoption of Spring RCP. I personally feel that requiring new app developers to learn yet another complex piece of machinery (OSGi) in addition to all the rest of Spring Rich (which is significant by itself
) would not be beneficial to the project's uptake.<BR><BR>Just my $.02 worth - boy, I hate how the current economy makes my opinions worth less each month :-)<BR><BR>Thanks,<BR>Larry.<BR><BR>Kevin Day wrote:</TT>
<BLOCKQUOTE cite=mid:REY1UFNUTiZDVDs0Ji0+NTY1Nzg1NzE4@satchel type="cite">
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR><FONT face=Arial size=2>
<DIV>Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox project is the baseline OSGi implementation).</DIV>
<DIV> </DIV>
<DIV>From my perspective, I don't think that OSGi is necessarily appropriate for a lot of GUI apps (although I do think it probably has more applicability than we might give it credit - even a simple music player could benefit greatly from a pluggable codec system). From my perspective, the *module* approach is the important thing. And if we are going to do modules, we might as well do something that is at least upwards compatible with OSGi. Certainly, the full OSGi functionality is not necessary for most apps - I actually a think a very small subset would be appropriate - and this sub-set could be run inside AND outside an OSGi container with a little bit of Spring DI magic.</DIV>
<DIV> </DIV>
<DIV>Here's the basic premise: Because OSGi supports dynamic loading and unloading of modules, they have been forced to address the issue of dynamic dependency management. The core result is that modules do *not* interact directly with each other. Instead, they either locate other modules (using a service locator type pattern), or they have those modules injected (using the whiteboard pattern). Time has shown that the dynamic dependency injection pattern is more reliable, easier to test and results in more flexible systems (allowing modules to be dynamically loaded and unloaded without impacting the operation of the application). In dynamic environments, it also makes service consumers much, much simpler to write (there is almost no boilerplate code - this is all refactored up into the framework).</DIV>
<DIV> </DIV>
<DIV>Most importantly, modularity forces better design practices overall. There are absolutely cases where functionality is so closely tied together that it will always reside in the same module - but I suspect that a lot of that sort of thing is occuring in the current code base because of the use of service locator type patterns instead of dependency injection (could be wrong on that, and I certainly don't want to step on any toes - but sometimes it's healthy to have an outsider question a design decision :-) ).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>This actually raises an interesting question that I hope someone with a deeper history in the Spring-RCP project can answer: How did the original decision to depart from Spring IOC/DI come about in the RCP project? Was it b/c of objection of creating and maintaining tons of Spring xml files, or was there some other reason? I think that maybe by understanding this, we may learn many of the things that need to be considered as we have the current discussion. It's super easy to set back at the end of years of development and question design decisions that were made early on - and in doing so, it's easy to miss some extremely important detail that went into the decision.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT></BLOCKQUOTE><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML>
|
