ZK Spring 3.1.1 MVVM Use @Scope/@Component or No?

asked 2013-03-19 05:02:12 +0800

rickcr
704 ● 7

updated 2013-03-19 13:36:49 +0800

Trying to follow the documentation and small talks on spring http://www.zkoss.org/documentation/zkspring is a bit confusing since different approaches seem to be taken.

Currently, I'm defining my ViewModels and injecting resources like so (since somewhere I saw this approach used):

 @org.springframework.stereotype.Component("myVM")
 @Scope("prototype")
 public class MyViewModel {

     @Resource
     private SomeService someService;

In my ZUL I bind to this ViewModel...

<?variable-resolver class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
<div id="foo"  apply="org.zkoss.bind.BindComposer"   
    viewModel="@id('vm') @init(myVM)">

Is this an OK approach to take or should I not be declaring my ViewModels as Spring managed components and instead do...

      @VariableResolver(org.zkoss.zkplus.spring.DelegatingVariableResolver.class)
      public class MyViewModel {

          @WireVariable
          private SomeService someService;

(ZUL would then use the full class name)

What is the preferred approach? Also, if the first approach is valid, is prototype scope ok or should I maybe be using Desktop scope?

EDIT

Follow up: per the developer Doc (not the Spring docs which is why there is confusion) they recommend the first approach, but the developer doc also mentions, annotating your Service classes that are to be wired in your view models with

 @Scope(proxyMode=ScopedProxyMode.TARGET_CLASS)  
 public class MyServiceImpl implements MyService {

I understand the rationale for this if you were going to hold some state in that bean, but if you are SURE your Service class is going to act only as a singleton, can we leave that off? ViewModels won't be living longer than your singleton service classes so I'd think this would be ok? (Obviously for any beans you want to inject with prototype scope, the proxyMode=ScopedProxyMode.TARGET_CLASS make sense.) Most of my Service classes are simply data access services that hold no state.