Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version
|
From: Kevin D. <ke...@tr...> - 2008-07-08 21:54:40
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>I think that this approach exactly inverts the ServiceLocator approach.</DIV>
<DIV> </DIV>
<DIV>In the current RulesValidator, there is an explicit call to <FONT size=2>(RulesSource) ApplicationServicesLocator.services().getService(RulesSource.</FONT><B><FONT color=#7f0055 size=2>class</B></FONT><FONT size=2>);</FONT><BR></DIV>
<DIV>this call is the root of the dependency issue under discussion.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>By inverting the problem, we can remove references to the static ApplicationServicesLocator.services() method entirely. Instead, the configuration of the object is factored out, and is triggered on registration of the object with the service registry. This last point (configuration occurs on registration) is actually pretty important because it drives the direction that dependencies are created. Instead of registring object foo with service A, we allow A to be notified when objects of type Foo become available. Service A (or preferably a handler such as Spring DM) then registers the object with the service. This enforces decoupling between objects and the services that operate on them. (Ironically, the 'ServiceRegistry' isn't really a registry of services at all - it's a registry of objects that services may want to operate on. In most cases, the service itself will never be registered with the registry). Perhaps some
renaming is called for...</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Anyway, the result of this in the current refactored example is that we are not injecting the ApplicationServicesLocator object into the RulesValidator. We are injecting the dependency that RulesValidator actually needs (RulesSource). At a functional level, RulesValidator should not need to know about ApplicationServicesLocator to properly function.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Objects themselves are very rarely, if ever, actually aware of the service registry. The framework itself does most (if not all) of that interaction on the object's behalf. The difference is subtle, but it completely unravels the dependency issue and makes modular development possible (as well as dynamic loading/unloading and all of the interesting stuff that comes with this kind of decoupling).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>- K</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> Tue, 08 Jul 2008 16:23:52 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV>
<DIV> </DIV></DIV><TT>In this approach haven't we just replaced the ServiceLocator with a ServiceRegistry - with all the same problems? Meaning that every object needs to "find" the ServiceRegistry, either by having it be a static singleton, or having declarative XML to DI it. This leads us right back to the earlier problems we had with the ServiceLocator. Or, have I misunderstood something in your proposal Kevin?<BR><BR>Thanks,<BR>Larry.<BR><BR>Kevin Day wrote:</TT>
<BLOCKQUOTE cite=mid:REY4UlhWUyksKyY9Ji0+NjY4NTYwMjUw@satchel type="cite">
<META content="MSHTML 6.00.2900.3059" name=GENERATOR><FONT face=Arial size=2>
<DIV>How about we start with a concrete example of how the service locator is currently used, and consider how it could be refactored?</DIV>
<DIV> </DIV>
<DIV>Here's a simple example:</DIV>
<DIV> </DIV>
<DIV>Currently RulesValidator has the ability to set a RulesSource object in the constructor, or if none is specified, it uses <FONT size=2>ApplicationServicesLocator to look up a RulesSource.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Another approach is to consider that we know that any given RulesValidator is *always* going to need a RulesSource. So we provide a setter for rulesSource (and probably ditch the variable pass in the constructor). When a RulesValidator is created, it is registered with a ServiceRegistry. The ServiceRegistry sends notifications that a new RulesValidator has been registered.</DIV>
<DIV> </DIV>
<DIV>We also have a Configurator object that has been created that listends to the ServiceRegistry. When new objects are registered, it injects resources into them. So as the RulesValidator is registered, the Configurator becomes aware of it, and injects the appropriate RulesSource. For the generic case, a default RulesSource will get injected. If a given RulesValidator needs a specific instance, the Configurator can determine which one to provide using a number of different strategies (xml, annotations, convention or any of a ton of other ways of declaritively specifying this kind of thing).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Advantages of this approach:</DIV>
<DIV> </DIV>
<DIV>1. The RulesValidator needs no knowledge of the ServiceRegistry - that dependency is completely gone.</DIV>
<DIV>2. The RulesSource needs no knowledge of the ServiceRegistry (Spring DI should be able to take care of the registration as it creates the RulesSource)</DIV>
<DIV>3. The behavior of configuration of objects becomes factored out into a separate entity (Configurator, or whatever). There is no longer any self configuration, which keeps the RulesValidator and RulesSource clean.</DIV>
<DIV> </DIV>
<DIV>If the Configurator is in a separate 'module' (or we follow appropriate design guidelines to ensure there isn't dependency creep), it may be possible to have different implementations of the basic configuration policy (i.e. one using xml files, one using annotations, one 'by-convention', etc...).</DIV>
<DIV> </DIV>
<DIV>Disadvantages of this approach:</DIV>
<DIV> </DIV>
<DIV>1. The service registry becomes more complicated (it has to support registration, and possibly deregistration, event notifications)</DIV>
<DIV>2. The service registry still needs to be made available (although I suspect that in most cases this can be factored out into Spring DI). If it does need to be made available, I believe that it should be done by injection (at least at the module level) and not via static lookup. If a module wants to store a copy of the service registry in a static variable with global module scope, then so be it - but I think the overall framework should not require this.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Comments? I think it may be worthwhile to take a look at a bunch of cases like this and make sure that it really makes sense.</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..." moz-do-not-send="true"><FONT color=#0000ff><lst...@au...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..." moz-do-not-send="true"><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Tue, 08 Jul 2008 14:59:53 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV>
<DIV> </DIV></DIV>Peter De Bruycker wrote:
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite">2nd attempt:<BR><BR>Can we reach a consensus here?<BR>I think we need to go as fast as possible, to keep the momentum going...<BR><BR>1. code organization:<BR>
<UL>
<LI>core
<LI>application: window, dialogs, page, view, action, ...
<LI>binding: validation, binding, forms
<LI>resources </LI></UL>2. singleton/service locator:<BR><BR>Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...<BR></BLOCKQUOTE><BR>I'm still unclear on how we do this without an explosion of XML or intermediate factories, lots of boilerplate (including additional members on objects), or some other nasty artifact that makes the platform difficult to use. Maybe I missed how this was to be done in the earlier email exchange, or I'm just being dense. Could you please elucidate how we get rid of the service locator and keep the solution simple to implement even with dynamic objects?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR>3. osgi support<BR><BR>First make sure we have something working, then see what we can do to improve?<BR></BLOCKQUOTE><BR>Do you mean to get the basic modularity cleaned up first and then look at OSGi, or do you mean get OSGi working right away?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR><BR>Again: I think we need to go fast, so we have something working as soon as possible.<BR><BR><BR>I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge!<BR><BR><BR>regards,<BR>Peter<BR></BLOCKQUOTE><BR>Good to see things getting ramped up!<BR><BR>Thanks,<BR>Larry.<BR><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
</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>
|
