Spring is a popular framework, however I have difficulties to see in which situation the framework would actually help.
Currently I'm using the following:
* Tomcat
* Jersey
* Jackson
* Hibernate
Together this results in a Webservice, created by annotations, automatic JSON (un)marshalling and a comfortable Object/Relational Mapping.
So honestly at the moment I'm not missing anything, but I might just not know what great thing I'm missing... Could you help me out with this?
Thank you
Spring is a big framework providing a lot of functionality. It's hard to talk about advantages without knowing what functionality are you trying to use in the project.
Most probably you talk about Spring as an IoC container. It is very important part of Spring, but there is also AOP, transaction management, JDBC abstraction layer, authentication and authorization, testing and some more.
In a nutshell, Spring offers you uniform way to control dependencies between your objects. This is called inversion of control or dependency injection. Using it you can create pluggable, testable code that is easy to maintain.
In addition it gives you gazillion utility classes that just make life easier. For example, Hibernate is much easier to maintain via Spring facilities. It kind of brings together many different technologies under the same roof.
Related
What are the enumerated benefits to using the Spring template classes such as RestTemplate, JdbcTemplate, JpaTemplate, JdoTemplate, JndiTemplate JdoTemplate etc?
I'm looking for the general benefits of using these classes as best practice design, for example the thread safeness of these classes. Or if someone could point me to the section of the Spring documentation that discusses the same I would accept that as well.
Less boilerplate code
More cohesive exceptions handling (e.g. JDBC drivers checked exceptions are translated to meaningful runtime exceptions)
Easier and uniform configuration (almost everything can be configured in Spring context files)
Automatized resource management (like, for instance, closing DB connections)
Note, that not all templates are equally useful. For instance jdbcTemplate is a pure gem, I can't live without that (mostly because JDBC is not the best interface one can imagine), on the other hand jpaTemplate does not bring so many advantages.
Note, that if you use given template, your code becomes dependent on Spring interfaces, so Spring is not only dependency mechanism for your application, but becomes also part of it - Spring is no longer easily replacable with something else (Google Guice, CDI). However, given the fact Spring is a pretty good peace of code, I would not be worried about that aspect.
What is the Difference between Spring IOC and Spring AOP and their Importance ?
Have you searched the web for IoC and AOP? There are a lot of references to both.
In a nutshell, IoC allows an external force to determine what implementation will be used by code rather than the code determining the implementation. The "external force" might be a configuration file, a unit test, other different code, etc.
AOP allows cross-cutting concerns to be implemented outside of the code affected by those concerns.
The "purpose" of Spring includes IoC and AOP, but goes quite a ways beyond that in its scope.
For more details please check.
Inversion of Control Containers and the Dependency Injection pattern and
Aspect-oriented programming
Also check this
What is AOP, Dependency Injection and Inversion Of Control in Simple English
IoC, AOP and more
Spring IOC: In simple answer normally you create object with new operator and set yourself for getter and setter. So, yes we use new operator in Java to create object. There is no any bad in doing this. But, when your project size grows and lots of developers are working, and you want to achieve POJO-based programming, you can use DI. So then maybe your question arises - why I can not code it myself? Of course you can use the power of reflection, annotation, and XML. But, some other had already coded this then why not reuse the third party one? There are lots of options for you to choose; Spring can be the best one. It manages your object life cycle from object creation to its destruction. You use the objects created and set by Spring DI container but you do not create them yourself.
Spring AOP: It is related to cross cutting concern. What it mean is in large system the common functionality is scattered throughout different modules. So AOP provides an easiest way to take out a common implementation in the form of 'aspect'. You can also in this case write own implementation using proxy concept but you can reuse the code of proxy based that is implementation of APO alliance using Spring.
Objective of Spring IOC is to reduce explicit dependencies between components, while purpose of Spring AOP is to wire components together possibly by enforcing certain common behavior (read: NOT Interface)
Since purpose of Spring AOP is to enforce certain behavior across components.So, Spring IOC comes in handy to achieve this purpose
I m a newbie & i m good at Struts framework. Today i tried a tutorial for Spring MVC Framework.
The example url that i tried following is as below:
http://static.springsource.org/docs/Spring-MVC-step-by-step/part6.html
I think they have made this tutorial much more complex especially near its end. I saw some errors mainly typos in part 5, part 6 of tutorial. I found Spring framework as not properly organized and how would we know what classes to extend especially when their names are so weird (pardon my language) e.g. AbstractTransactionalDataSourceSpringContextTests.
Overall i found that Spring is making things much more complex than it should be. I'm surprised why there is such a hype about Springs being very easy to learn.
any suggestion how to learn spring easily ? how to judge what to extend ? is there a quick reference or something?
The tutorial you have referred to covers all the layers of the application - data access, business logic and web. For someone who is looking to only get a feel of Spring MVC, which addresses concerns specific to the web layer of the application, this could be more information than required. Probably that is why you got the feeling that the tutorial is complex.
To answer your questions, Spring is easy to learn because the whole framework is designed to work with POJOs, instead of relying on special interfaces, abstract classes or such. Developers can write software as normal Java applications - interfaces, classes and enums and use Spring to wire the components up, without having to go out of the way to achieve the wiring. The tutorial you have referred to tries to explain things in a little bit more detail than experienced programmers would typically do in a real application, probably because the authors wanted the readers to get enough insight into how Spring works so that concepts are understood well.
In most applications (regardless of their size or nature), there is typically no need to extend Spring classes or to implement specialised classes. The Spring community is quite large and an even larger ecosystem of readily available components exists that integrate with Spring. It is therefore very rare that one has to implement a Spring component to achieve something. For example, let us take the example of the data access layer. Different teams like using different approaches to accessing databases. Some like raw JDBC, others like third-party ORMs like iBatis or Hibernate while some others like JPA. Spring distributions contain classes to support all these approaches. Similarly, lets say someone was looking to incorporate declarative transaction management in their application. Again, transaction management can be done in many different ways and a large number of transaction management products are available for people to use. Spring integration is available for most of these products, allowing teams to simply choose which product they want to use and configure it in their Spring application.
Recent Spring releases have mostly done away with extensive XML based configuration files, which being external to the Java code did make Spring application a bit cumbersome to understand. Many things can be done nowadays with annotations. For example,
#Controller
public class AuthenticationController
{
...
}
Indicates that AuthenticationController is a web MVC controller class. There are even ways to avoid using the Controller annotation and follow a convention-over-configuration approach to simplify coding even further.
A good and simple tutorial to Spring MVC is available at http://www.vaannila.com/spring/spring-mvc-tutorial-1.html. This tutorial uses XML based configuration for Spring beans instead of annotations but the concepts remain the same.
I have seen tutorial you follow , Its seems you have follow wrong one first , you first tried to simple one, Instead of tutorials you should go for book first
I recommend you two books to understand the power of Spring
spring in action and spring recipes.
For practical you can use STS a special ide for spring project development.Its have some predefined template you dont't need to write whole configuration yourself.
In starting just see simple tutorials like Spring mvc hello world , form controller than go for big ones
Spring is very cool , All the best.
I love the concept of DI and loosely coupled system, a lot. However, I found tooling in Spring lacking at best. For example, it's hard to do "refactoring", e.g. to change a name of a bean declared in Spring. I'm new to Spring, so I would be missing something. There is no compiling time check etc.
My question is why do we want to use XML to store the configuration? IMO, the whole idea of Spring (IoC part) is to force certain creational pattern. In the world of gang-of-four patterns, design patterns are informative. Spring (and other DIs) on the other hand, provides very prescribed way how an application should be hooked up with individual components.
I have put Scala in the title as well as I'm learning it. How do you guys think to create a domain language (something like the actor library) for dependency ingestion. Writing the actual injection code in Scala itself, you get all the goodies and tooling that comes with it. Although application developers might as well bypass your framework, I would think it's relatively easy to standard, such as the main web site/app will only load components of certain pattern.
There's a good article on using Scala together with Spring and Hibernate here.
About your question: you actually can use annotations. It has some advantages. XML, in turn, is good beacause you don't need to recompile files, that contain your injection configs.
There is an ongoing debate if Scala needs DI. There are several ways to "do it yourself", but often this easy setup is sufficient:
//the class that needs injection
abstract class Foo {
val injectMe:String
def hello = println("Hello " + injectMe)
}
//The "binding module"
trait Binder {
def createFooInstance:Foo
}
object BinderImpl extends Binder {
trait FooInjector {
val injectMe = "DI!"
}
def createFooInstance:Foo = new Foo with FooInjector
}
//The client
val binder:Binder = getSomehowTheRightBinderImpl //one way would be a ServiceLoader
val foo = binder.createFooInstance
foo.hello
//--> Hello DI!
For other versions, look here for example.
I love the concept of DI and loosely
coupled system, a lot. However, I
found tooling in Spring lacking at
best. For example, it's hard to do
"refactoring", e.g. to change a name
of a bean declared in Spring. I'm new
to Spring, so I would be missing
something. There is no compiling time
check etc.
You need a smarter IDE. IntelliJ from JetBrains allows refactoring, renaming, etc. with full knowledge of your Spring configuration and your classes.
My question is why do we want to use
XML to store the configuration?
Why not? You have to put it somewhere. Now you have a choice: XML or annotations.
IMO,
the whole idea of Spring (IoC part) is
to force certain creational pattern.
In the world of gang-of-four patterns,
design patterns are informative.
ApplicationContext is nothing more than a big object factory/builder. That's a GoF pattern.
Spring (and other DIs) on the other
hand, provides very prescribed way how
an application should be hooked up
with individual components.
GoF is even more prescriptive: You have to build it into objects or externalize it into configuration. Spring externalizes it.
I have put Scala in the title as well
as I'm learning it. How do you guys
think to create a domain language
(something like the actor library) for
dependency ingestion.
You must mean "injection".
Writing the
actual injection code in Scala itself,
you get all the goodies and tooling
that comes with it.
Don't see what that will buy me over and above what Spring gives me now.
Although
application developers might as well
bypass your framework, I would think
it's relatively easy to standard, such
as the main web site/app will only
load components of certain pattern.
Sorry, I'm not buying your idea. I'd rather use Spring.
But there's no reason why you shouldn't try it and see if you can become more successful than Spring. Let us know how you do.
There are different approaches to DI in java, and not all of them are necessarily based on xml.
Spring
Spring provides a complete container implementation and integration with many services (transactions, jndi, persistence, datasources, mvc, scheduling,...) and can actually be better defined using java annotations.
Its popularity stems from the number of services that the platform integrates, other than DI (many people use it as an alternative to Java EE, which is actually following spring path starting from its 5 edition).
XML was the original choice for spring, because it was the de-facto java configuration standard when the framework came to be. Annotations is the popular choice right now.
As a personal aside, conceptually I'm not a huge fan of annotation-based DI, for me it creates a tight coupling of configuration and code, thus defeating the underlying original purpose of DI.
There are other DI implementation around that support alternative configuration declaration: AFAIK Google Guice is one of those allowing for programmatic configuration as well.
DI and Scala
There are alternative solutions for DI in scala, in addition to using the known java frameworks (which as far as I know integrate fairly well).
For me the most interesting that maintain a familiar approach to java is subcut.
It strikes a nice balance between google guice and one of the most well-known DI patterns allowed by the specific design of the scala language: the Cake Pattern. You can find many blog posts and videos about this pattern with a google search.
Another solution available in scala is using the Reader Monad, which is already an established pattern for dynamic configuration in Haskell and is explained fairly well in this video from NE Scala Symposium 2012 and in this video and related slides.
The latter choice goes with the warning that it involves a decent level of familiarity with the concept of Monads in general and in scala, and often aroused some debate around its conceptual complexity and practical usefulness. This related thread on the scala-debate ML can be quite useful to have a better grip on the subject.
i can't really comment on scala, but DI helps enforce loose coupling. It makes refactoring large apps soooo much easier. If you don't like a component, just swap it out. Need another implementation for a particular environment, easy just plug in a new component.
I agree! To me he way most people use Spring is a mild version of hell.
When you look at the standard Springified code there are interfaces everywhere, and you never really know what class is used to implement an interface. You have to look into some fantastic configuration to find that out. Easy read = not. To make this code surfable you need a very advanced IDE, like Intelly J.
How did we end up in this mess? I blame automated unit testing! If you want to connect mocks to each and every class you can not have dependencies. If it wasn't for unit testing we could probable do just as well without loose coupling, since we do not want the customer to replace single classes willy nilly in our Jars.
In Scala you can use patterns, like the "Cake Patten" to implement DI without a framework. You can also use structural typing to do this. The result is still messy compared to the original code.
Personally I think one should consider doing automated testing on modules instead of classes to escape this mess, and use DI to decouple entire modules. This strategy is by definition not unit testing. I think most of the logic lies in the actual connections between classes, so IMHO one will benefit more from module testing than unit testing.
I cannot agree that XML is problem in Java and Spring:
I use Spring and Java extensively without to much XML because most configuration is done with annotations (type and name is powerful contract) - it looks really nice. Only for 10% cases I use XML because it is easier to do it in XML than code special solution with factories / new classes / annotations. This approach was inspired by Guice and Spring from 3.0 implements its as JSR-330 (but even that I use Spring 2.5 with spring factory configured with JSR-330 annotations instead of default spring-specific #Autowired).
Probably scala can provide better syntax for developing in DI style and I'm looking at it now (pointed Cake Pattern).
What are the advantages/disadvantages of Seam over Spring? Why would I use Seam in lieu of Spring?
Is there anything that can be done in Seam that can't be done in Spring? Anything in Spring that can't be done in Seam?
What about stateful/stateless architecture? I am a Spring user, so I am biased, naturally.
Why Spring?
Cleaner code
Streamlined application configuration
Nice integration with popular open source products
First class AOP support
Enterprise-scale security: Acegi
Highly flexible MVC
Abstracted data access (JDBC is OK)
Enterprise Java without EJB
Testing is easy
Why Seam?
Merge Java EE 5 standards (EJB 3.0, JPA, JSF, Annotation) seamlessly
Stateful by design
Bijection
Integrated Ajax (ICEfaces and Ajax4JSF)
Business process integration (jBPM)
Business rules integration (Drools)
Workspace management
Deliver complete stack (from JBoss & RedHat)
Seam Text and EL enhancements
Probably will be a standard (JSR-299: Web Beans)
From Framework Deathmatch: Spring vs Seam. Thomas Wiradikusuma (Spring). Joshua Jackson (Seam). Java User Group Indonesia. JaMU 07.03. March 17, 2007 power point presentation here
although seam does have many advantages over spring, there is a magic word that really is worth paying attention to and this is PERFORMANCE!!! if you are not worried about performance issues I would go with seam. From the other hand if you want your application to be as fast as possible and your hardware is limited I would use spring. I am not saying that you can not develop fast applications with seam, but in order to do this you really need to know what you are doing. I have used both of them (i am not a guru in any of them) and what I found out is that although spring needs more effort to build what you want, at the end the result is more flexible and is performing better. I do not think that there is something that can be done in one framework that it can not be done in the other, saying that, remember that I am not an expert to any of those.
Seam will give you a pretty, ah, seamless, integration between the components that make up the seam stack. All very nice as long you keep within that stack, and within the seam model and foing things. It all starts to look a little less convincing as soon as you start doing something unusual, though.
If it's not too much of a generalisation, Seam is very "microsofty" in that regard. This isn't a bad thing, it's just a stylistic thing. Spring is more open-ended and takes more effort to get going, but it's ultimately more flexible, and a lot more open.
You can use Spring and Seam together - Spring for backend components, Seam for enhancement of web layer (JSF/GWT/Wicket) and other stuff. Seam offers a lot of Spring functionality (i.e. IoC container, transaction managment) - in your project you can decide - witch implementation to use.
More details on integrating Seam with Spring - "Seam in Action - free bonus chapter"
Let's compare the two.
What is common?
Both are open source, follow MVC architecture and has a servlet based front controller.
Advantages of Spring MVC
Extension of Struts.
View can be developed using JSP and HTML. You can also plugin other's like PHP or velocity.
Has large number of controllers predefined.
Integrated out of the box with Spring framework.
Advantages of Seam
Extension of JSF
View can be developed using JSF component library. There are large number of vendors to choose from.
Integrates JPA entities with Web layer
Annotation based validation
Integrates with EJB 3.0
Out the box jBPM support which provides process flow definitions.
Integrates with Drools where you can define web layer business rules.
Good community support.
Conclusion
Since Seam is built on JSF, it has large number of UI Component libraries to pick from. It reuses Java EE stack better. It has lot of interesting modules integrated beforehand.
Spring MVC is built on top of Struts and Spring, so it will reuse Spring framework stack far better than others. But the view is built using JSP, so we have to rely on JSP tag library vendors to build rich components.
Seam framework would be a better choice as Spring framework is anyway extensible enough to be leveraged by Seam.