I think <bean> with DI would be useful for a pattern where service A depends bean B which in turn depends on service C. Bean B could be a stateful object that manages some states on behalf of service A. Another service D may also depend on another instance of bean B with independent states.
We can somehow simulate this pattern now with threaded service model, if service A and service D do not interleave. We can also simulate it with a singleton service that has a state object on every parameter. However this doesn't look very OO. Yet we can also do it with ObjectProvider. In this case the ObjectProvider of bean B will have dependency on all the services B depends on. When it provides bean B, it will instantiate it, inject the dependencies, and return the bean. <bean> + DI shall be able to reduce the need for the OP in this case. On the other hand, are we still using the setters on the bean for DI? A bean's setter may be there for application use rather than DI. Can we describe the bean so that some setters are ignored. Can we configure beans (or services) to use injectXXX for DI rather than setters? Albert --- Knut Wannheden <[EMAIL PROTECTED]> 內容： > I think it would be quite interesting to know what > others think about > this proposal as I'm not sure how I'd personally use > it either. > > I have in the past argued for supporting > interface-less services > because I think it would be great for prototyping > and exploring the > problem domain. Eventually, as I'm clear on the > responsibilities of > the services, I'd however convert the beans to > services. > > What this would look like with a top-level <bean> > element: If I at > some point decide to add an interface to my bean and > turn it into a > service then I have to both change the <bean> > element into a > <service-point> *and* change all references to it. > References exist as > type declarations of autowired constructor > parameters and setter > parameters, any uses of the "bean:" object provider, > and possibly also > <set-bean> elements. This means quite a bit of work, > which I think in > the end would keep me from using <bean>s for > prototyping. > > So I am wondering how others who have argued for > interface-less > services feel about this proposal. What problems > would (or wouldn't) > it solve for you? > > I'd prefer if the <service-point> element could be > used as is. Beans > would simply declare the bean class itself as their > "interface". All > other restrictions (e.g. service model) could be > enforced by HiveMind. > But I can see how this could be confusing. > > Apart from that there is something I think would be > even more useful > wrt beans: A HiveMind service or a programmatic > interface which can be > used to instantiate and / or autowire beans. I find > myself quite often > defining a factory or repository type of service > which builds POJOs > and where access to autowiring would be very useful. > > --knut > > On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship > <[EMAIL PROTECTED]> wrote: > > Part of this has been discussed on the wiki: > > > > > http://wiki.apache.org/jakarta-hivemind/PojoServices > > > > People chafe at the use of interfaces for > one-time use objects, but > > still want all the dependency injection that > BuilderFactory provides. > > > > Adding a new <bean> element would solve a fair > amount of this. > > > > It wouldn't be quite inline, it might be more > like: > > > > <set-object property="databaseAccess" > value="bean:DatabaseAccess"/> > > > > ... > > > > <bean id="DatabaseAccess"> > > > > <construct class="mypackage.DatabaseAccess"> > > <set-object property="daoService" > value="service:DAOService"/> > > </construct> > > </bean> > > > > In this way, beans would be another namespace like > services and > > configurations, could have visibility, etc. > > > > I think we could also dress up the instance: > object provider to do > > some *simple* configuration of the object, i.e.: > > > > > instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringProperty='some > > string' > > > > You can already do some of this using > hivemind.lib.BeanFactory. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ===== Are you an MBA? Check out http://www.mba.hk for value added services. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
