spring framework
I have recently started working on a project using Spring Framework. I have observed that at some places in the code the spring framework is being used to get objects as beans through the config.xml and BeanFactory. While at other places the new operator is being used.
Is there any special consideration to be kept in mind as to which classes should be intantiated directly and which through Spring? In such a case whats a good practice?
[451 byte] By [
Andraa] at [2007-11-26 13:46:35]
In all candor I don't know the exact answer to your question. If you'd post some code showing both it might help a bit but just to get you going, here's a link.
http://www.google.com/search?hl=en&lr=&q=Java+%2B+Spring+Framework
Remember, Google is ALWAYS your best friend in situations like this.
Hope this helps,
PS.
> Is there any special consideration to be kept in mind as to which classes should be intantiated directly and which through Spring?
In such a case whats a good practice?
Beans typically have getters and setters. In spring apart from these beans you can also represent any object. In that case, you may
not find empty constructor, or getters/setters. For that you need tell spring to use constructor based approach to instantiate.
I know how to use Spring my question is a little more philosophical in nature. Now in the code that I am mentioning, I have seen spring being used BeanFactory factory = new XmlBeanFactory(new FileSystemResource(
"./ch4/src/conf/beans.xml"));
ConstructorConfusion cc = (ConstructorConfusion)
factory.getBean("constructorConfusion");
while at other places
Test tt = new Test(alpha, beta, charlie);
is being used. My question is that once a decision has been made to use spring shouldnt it be used for instantiating all the objects through it. And are there any exemptions?
Ok now I see where you're going I can offer something more constructive.
As the other poster said this is most likely a matter of conformance to the Java Bean standard which says among other things that there shalt be getters and setters for all relevant properties.
The first example you provide (as I'm sure you know) is using reflexion to build the object through a factory. The second is direct invocation. Using a factory is tidier if you can't be certain exactly which form of a thing (assuming you have multiple forms) you are going to be using. It removes the whole instance of question. Obviously the multiple forms would all have a common interface requirement.
Direct invocation is less resource consumptive if you only have one form of a thing or you are absolutely certain of the form you need. Now that said, if a factory exists I'd recommend using it. There are certainly cases where you might not want to but I would expect those to be very much the exception.
Hope this helps,
PS.
spring doesn't stop you from instantiating an object outside spring framework. But you have to make sure that you create all the
dependency object and wire them together (which spring does by default). In some cases, you might want to have only one object in
the application which is also managed by spring. If you instantiate such objects outside, it would defeat its purpose.
In short, be careful while instantiating outside - always ask spring to do it for you.
> Ok now I see where you're going I can offer something
> more constructive.
>
> As the other poster said this is most likely a matter
> of conformance to the Java Bean standard which says
> among other things that there shalt be getters and
> setters for all relevant properties.
>
> The first example you provide (as I'm sure you know)
> is using reflexion to build the object through a
> factory. The second is direct invocation. Using a
> factory is tidier if you can't be certain exactly
> which form of a thing (assuming you have multiple
> forms) you are going to be using. It removes the
> whole instance of question. Obviously the multiple
> forms would all have a common interface requirement.
>
> Direct invocation is less resource consumptive if you
> only have one form of a thing or you are absolutely
> certain of the form you need. Now that said, if a
> factory exists I'd recommend using it. There are
> certainly cases where you might not want to but I
> would expect those to be very much the exception.
>
> Hope this helps,
>
> PS.
thanks for the reply. its a little more clear now, however going back to the question if the attributes being passed to the constructor i.e. alpha, charlie etc are determined at runtime, I mean their values are determined at runtime, what would be the preference in such a case. though Spring offers defining it in the the config. xml file as follows:-
<bean id="constructorConfusion"
class="com.apress.prospring.ch4.ConstructorConfusion">
<constructor-arg>
<value>90</value>
</constructor-arg>
</bean>
but what if instead of value 90, its a value which would be calculated at runtime, does such a scenario warrant the use of direct invokation using new operator.
> thanks for the reply. its a little more clear now,
> however going back to the question if the attributes
> being passed to the constructor i.e. alpha, charlie
> etc are determined at runtime, I mean their values
> are determined at runtime, what would be the
> preference in such a case.
If they're only known at runtime or from calculations, then it's impossible to put them in the configuration file. Those have to be instantiated using new.
> though Spring offers
> defining it in the the config. xml file as follows:-
> <bean id="constructorConfusion"
> class="com.apress.prospring.ch4.ConstructorConfusion">
>
> <constructor-arg>
> <value>90</value>
> </constructor-arg>
> </bean>
>
>
> but what if instead of value 90, its a value which
> would be calculated at runtime, does such a scenario
> warrant the use of direct invokation using new
> operator.
I think it does.
%
As most people who know me are aware I'm not a fan of frameworks. I've yet to meet one that I liked and yes I've used Struts and Spring and a good half dozen others over the years. My objections to frameworks are these;
1. Invariably (so far) they require that more pieces be built to accomplish the same ends.
2. They obfuscate the operations of the application by redirecting control, intelligence or information outside of the critical path. (Your example of the config file is a prime example of what I'm driving at here)
3. They work fine as long as you're inside their box. Step outside that box and it all goes out the window.
Does any of that mean you or me or someone else shouldn't use a framework? Not at all it just means that while I'm doing it I won't like it and I'll grumble about it. Does it mean that frameworks are BAD? Again not at all. If the framework helps achieve the one and singular goal of what we do (put usable software in front of the users) then it's a good thing and it should remain as part of the process. If it doesn't, then out it goes. What it does mean is that we should NEVER implement a framework or a technology or a pattern or anything unless and only unless it contributes to the goal.
All that said, you're using the Spring framework and that's wonderful if it is making your life easier, but I would recommend two things. First, be critical in your evaluation of whether it's helping you or not. Second, make absolutely certain that you know what's going on under the hood.
Now that I've waxed philosophical about frameworks (****** PS shut up already)
The question I would ask in this situation is this, is the information configuration information that is unlikely to change often? If the answer is yes then read it from the config file if it's volatile such as a calculated value for the sales price of a framitz then no it doesn't go there.
The other thing I would say is that a framework doesn't take away the need to perform rigorous design, rather it makes it even more necessary because with every framework I've ever dealt with, change is more difficult than it is without a framework using the tools of the platform in their most pure form.
Just my thoughts on the subject your milage may of course vary.
PS.
