|
From: Ken K. <kk...@kk...> - 2003-09-03 13:45:05
|
+1 rod...@in... wrote: >All, > >As I can see it the only arguable advantage that >PicoContainer has over Spring is that it can satisfy all >dependencies before allowing an object to be invoked, so that >an object can never be used when incompletely configured. I >don't like their constructor way of doing this, and I think >that it often makes sense to have optional properties, with >sensible default. So I've never been worried by this in >Spring. > >However, it's pretty easy to add optional dependency >checking. I've successfully prototyped the following, which >required very minor changes: >- add a new DTD attribute for the "bean" element called >dependencyCheck >- if this is set to true, XmlBeanFactory checks that all >properties on that bean have been set. If not it throws an >UnsatisfiedDependencyException. We can't do the PicoContainer- >style automatic wiring up as we can support multiple objects >of any type. They can only accomplish this because they >support only a single object of each type, which doesn't >satisfy the kind of real-world requirements I've used Spring >in. > >At present my prototype checks only Object properties >(presumably other beans in the factory). It might be good to >have three values for dependencyCheck: "no" >(default), "object" (collaborators) and "all" (primitives and >collaborators). > >As this is backward compatible and easy to do I'm inclined to >add it, if only for marketing value. There may be real value >in that it means that an init method wouldn't need to check >that a certain property was non-null. > >What do you think? Is this worthwhile? > >Regards, >Rod > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |