Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What are the reasons you should build your web application with raw Java Servlets or by using Spring MVC (or any other frameworks)?
Are there exceptions when you should avoid Spring MVC, what are the advantages of doing it with Raw Servlets?
If you're building a really quick and dirty demo that you have no intention of extending later, spring can result in a lot of additional configuration issues (not really if you've done it before, but I always end up fighting with it one way or another), so that might be a time to consider just using plain old servlets. Generally though, anything beyond just a super fast and dirty demo, using some form of MVC framework is going to make life in the future a lot easier and is also in line with best practices. Spring makes things super easy, just have to spend some time on the front end configuring everything.
I should note, there's nothing you can do with java servlets that you can't do with Spring. The big difference is setup time.
Edit: It's worth noting that when I posted this answer, I was unaware of Spring Boot that is actually quite easy to get up an running using either an embedded web server or a more conventional web container. Here's a link to a quick start example: http://projects.spring.io/spring-boot/#quick-start
Servlet technology is used for more generic server side extension for request-response paradigm.
And Spring just uses it for the Web application over HTTP.
And some quote from here:http://www.reddit.com/r/java/comments/29f3ul/why_is_spring_mvc_better_than_servlets_jsp/
Servlets are based upon a low-level API for handling requests and
responses. Web frameworks like Spring MVC are designed to make
building web applications, which handle HTTP requests and responses,
easier. Most Java web frameworks, including Spring MVC, use servlets
behind the scenes.
You CAN use servlets to write a web application, but you'll have to
handle all of the details manually. You'll get very little help with
typical web stuff like validation, REST, request/response body for
JSON, form binding, etc. You will end up writing lot of utility code
to support your web application.
Web frameworks, on the other hand, are designed to make all of this
stuff simple. With Spring MVC, you aren't bothered with manually
handling the request and response even though you can still get access
to them if you need to. Want to return JSON in Spring MVC? Just add a
#ResponseBody annotation and Spring will append it. Want RESTful URLs?
Easy. Input validation? Piece of cake. Want to bind form data to an
object? Simple. With servlets, you'd have to do all of this stuff
manually.
Using raw servlets can be a good learning experience though. It really
helps to clarify how web frameworks make life easy for you!
I have developed projects both with raw servlet and web app framework.
Framework gives you everything, only you need to is to setup and config the env, coding is much more easier. The result is that you will know nothing about web dev.
However, code with raw api and servlet gives you chance to gain experience and be a programmer.
I don't use Spring a lot. But I don't see how would it have big impact on the performance. MVC's can help, but they can create a mess and extra work and frustration.
The old good way is good enough for most projects implemented by one programmer. MVC's could help when there are more than one developer.
I would use a plain servlet/jsp for most projects. If I need reusable components, I use wicket. Servlets goes with JSPs/freemarker/velocity or other template engine for presentation.
If you follow a naming pattern for your Servlets/JSP, I don't think you need Spring MVC.
I find that, with the addition of Spring version 3+, it becomes much more easier to bootstrap a Spring Web application with all the basics. The advantage of Spring MVC is that once you've bootstrapped the application context and the database connection, it becomes incredibly easy to create new controllers and it follows a much more logic architecture that newer developers may actually find easier as they get more familiar with it.
In fact, at my previous place of work, we were in the process of building a Java Servlet Web application, but we found that we had to create our own architecture or spine of the application and that is actually more work. Spring can take care of that which means that developers can get on with the actually application logic instead of worrying about the architecture too much.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm an ASP.NET developer, I'm happy with ASP.NET MVC and Entity Framework...
I want to use Java EE in a new web project, but there is a lot of specifications and frameworks (jsf, ejb, hibernate ...),
I'm looking for the best combination of Java EE specification tu use for a big Web Project (I must use HTML5, Javascript, JQuery, Javascript Framework like Telerik Kendo UI, Json, Webservices ...) and I love MVC so I'm looking for the MVC support in Java EE
For now, I decided the deployment server: Debian + Glassfish
I don't care about learning curve, but I do care about stability and performance
You can use Spring Web MVC for following reasons.
Active Community
Great Documentation
Ease of learning
MVC Architecture Supported
Used in the Industry
You probably wanna go with Spring, MVC being only one of the reasons. I can't tell whether it is the best in the Java landscape (maybe it is, I love it), but given how widely used it is you will most likely find someone able to help whenever you run into something you can't figure out by yourself.
Same applies for Maven when it comes to dependency management. Another viable alternative would be Gradle, but Maven is probably used more widely.
I would also suggest keep your project "Mavenized", i.e. buildable without IDE. That does not mean don't use IDE of course, just make sure it is buildable right after pulling the project from the repository, without starting your IDE.
Just yesterday I read this great article that might help you adopt some good habits right from the start: http://www.jamesward.com/2014/12/03/java-doesnt-suck-youre-just-using-it-wrong
In fact there are many amazing Java EE tools and frameworks, I think the best combination will be using:
Spring framework, Hibernate ORM and JSF (precisely Primefaces) because they all have highly active communities, Good documentation with great tutorials.
I have very good experience with Tapestry5 and for the model layer JDBC templates or JPA(Hibernate) which is an ORM tool like Entity Framework.
Tapestry5 is a component based framework and it works nice. Great support for AJAX. They have a quite big community and a lot of components.
You can also use JSF (check primefaces, richfaces) + Spring(or CDI) + model layer
If you want something for rapid development use Vaadin or Liferay.
You can also go with Spring MVC which is also a good choice.
For testing use Selenium tests which are just great.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Hello I want to know if I can start learning Spring MVC even if I don't have any knowledge about JSP and Servlets, I used to program before in php and codeigniter. and now I want to start with java and I've heard that spring mvc is the most used framework out there.
Yes, you can start learning Spring MVC.
The problem(s) will begin when you need to debug Things That Go Wrong, because you won't have the background knowledge of the components Spring is built upon.
That's not necessarily a bad thing, but it will make some things take longer than they might otherwise. For the most part, you can learn JSP as you go along. You don't need to learn about servlets specifically, but Spring MVC relies on the Servlet Specification, which talks about things like Java EE scoping (e.g., request, session, etc.), JSPs, filters, and so on.
The "V" in "MVC" stands for "View". The Views in Spring MVC are all generally built on top of JSP's, which are in turn built on Servlets, so you will probably have to learn them at some point. That being said, much of the Spring MVC tutorial material out there starts at the beginning, so you can learn the entire technology stack as you go, although you may want to have a JSP guide or reference handy, as the Spring MVC material won't get into the gory details of JSP syntax.
Spring is used a lot but so is Apache Struts and a dozen of other frameworks so you should also consider whether you want to stick to a specific framework.
From my experience refactoring Spring code to something else is quite difficult so once you go with Spring you must stay with it for a long time especially if your project is complex.
From my experience learning JSP and some JSF would be more than enough for most projects and you would have more time to consider frameworks.
I used Apache Struts a lot and now I got back to using only standard Java tools so JSP, JSF and JPA.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a java developer, not seasoned, but I am familiar with most concepts reasonably well.
I recently built a website using Tomcat/JSP (~30 dynamic pages). I made the newbie mistake of including large sections of core logic in the JSP, using the rationalization that it's "just a simple project".
I learned the hard way. So I'm re-building the app now in google app engine using servlets and planning to use Velocity to implement it using a Model-View-Controller design pattern.
I'm also looking at Struts, but haven't used the framework before.
Can someone convince me why I should incorporate struts into this project? Is it really going to buy me a lot for a medium sized project of one or two people?
There is a clear cost in an extra learning curve with strut, will the benefits outweigh the costs? Or will the use of Velocity be enough to segregate the logic? Opinions?
I would look longer term than this project. As you saw, first time you use any technology is largely about making mistakes and learning from them. So this first project won't likely be a shining example of Struts usage once you're done.
Using Struts (and Tiles from what you indicate was a main concern: JSP copy and paste) will however be an excellent delve into "proper" MVC, i.e. it forces you to do things in a particularly structured way, and one which I happened to appreciate a lot, I was a big Struts fan.
That said, there are other options, e.g. Spring contains Spring MVC plus much much more. If you're going to invest in overcoming a learning curve, think about which framework will most benefit you overall in the medium term: which frameworks do employers in your area tend to look for, for example? At this point in time, I would go with Spring where I feel the momentum is but Struts is very good at what it does.
If you're going to learn a framework then I'd recommend Spring MVC over Struts. The learning curve isn't too steep and there are lots of Spring resources available on the internet.
Once you've got Spring in place you will find your application is much simpler to maintain and support. You'll also be able to add enhancements, like security, a lot easier.
First: don't let the name confuse you: Struts2 and Struts are very different frameworks.
Second: changing from JSP to Velocity can be a good or bad decisition, but that's not exactly the point. The point is to switch away from Model1 (rather ancient nomenclature, but still useful). That is, decoupling your view layer from your logic layer. (You can use JSP or Velocity for your view layer).
Furthermore, to decide your view layer is just a part of your architecture: you still must decide who will process the request and produce the data that will be sent to the view. The most basic option is to use plain servlets, but, again, it's better to use some framework. For this, there are a lot of frameworks in Java. The "action based" ones are a subset among them, perhaps the most simple to learn. Among them, the oldest is Struts; today the most used for new projects are (in no particular order) Struts2 , Spring MVC and Stripes - they are quite similar.
Learning to separate the logic is excellent. You can do that without using Velocity, Struts or any framework whatsoever, and you'll likely learn more about what it takes to do this separation if you try it with minimal help first.
Learning a framework (in fact multiple frameworks) is also worthwhile, but I wouldn't personally choose Struts as a first framework unless it's the one used by your employer or a prospective employer. If your employer is using Struts, I hope it's Struts 2, as Struts 1 is getting ancient.
The framework I like to work with the most is Wicket, but it's a radical shift from what you're currently looking at. SpringMVC is also definitely worth a look.
If your employer is already doing web development in Java using a framework, try to learn the framework that's actually in use, and ask your co-workers for help learning it.
Why you should learn Struts? My answer is: because employers often require knowledge of it, especially for maintaining of older projects. I didn't make any precise measurements, but I think that at my region JSF and Struts are used for web application development most often.
Struts is a quite old web framework, and it's quite clumsy to write modern AJAX GUIs with it, so there were created better frameworks. JSF is for me a bit less clumsy, but also has some problems. My favourite web frameworks are Vaadin and GWT, but I'm not suggesting anything for you - you should make the decision by yourself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
The Play Framework offers the following quick overview, but with the exception of the Groovy template engine (which you can get in Spring MVC if you want), Spring seems to offer all the same features and more...
Fix the bug and hit reload! Edit your Java files, save, refresh your browser and see the results immediately! No need to compile, deploy or restart the server. Spring does this, which can get annoying.
Stateless model Play is a real "Share nothing" system. Ready for REST, it is easily scaled by running multiple instances of the same application on several servers. Typical Spring applications have a stateless application tier; it's not purely RESTful unless you want to be, but Spring is "ready for REST".
Efficient template system A clean template system based on Groovy as an expression language. It provides template inheritence, includes and tags. Spring uses Java, but Groovy is an option too.
Resolve errors quickly When an error occurs, play shows you the source code and the exact line containing the problem. Even in templates. Spring does this as well.
All you need to create a cool web application Provides integration with Hibernate, OpenID, Memcached... And a plugin system. Spring integrates with everything and more.
Pure Java Code with Java, use any Java library and develop with your preferred IDE. Integrates nicely with eclipse or netbeans. Spring is pure Java as well.
Really fast Starts fast and runs fast! Subjective, but Spring is pretty quick.
So what does the Play Framework actually do differently than Spring MVC?
In a nutshell what can Spring do that Play framework cannot (and vice-versa)?
I find the "pure Java" claim on either side very funny.
Of course, it's unrealistic for a project to use absolutely nothing but java. Still, a "pure Java" label should have some standards, I don't think either framework qualifies.
Play actually modifies the semantics of Java language. That is all right as long as it's clearly specified. If you do some byte code manipulation, just be honest about it. Usually it's done by AOP-ish trick, instance methods are decorated with additional behaviors, their manifest behaviors - these written in the code, are usually preserved. This is not too hard to accept, we can pretend our code are subclassed by the framework and our methods are overridden with additional behavior.
In Play, one static method calling another static method in the same class can have magical effects, and the behavior is nothing like a method call. That is a huge problem, if a Java programmer can no longer be certain what a static method call is.
Spring - well, their Java part is still pure Java all right. But it's so magical(from java's POV), and depends so heavily on a heavy framework, calling Spring "pure Java", is like calling a burger "pure vege" if we overlook the meat. The meat is the best part!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Since Spring is able to use transactions just like EJB. For me, Spring is able to replace the requirement of using EJB. Can anyone tell me what are the extra advantages of using EJB?
Spring was developed as an alternative to EJB right from its inception, so the answer is of course you can use Spring in place of EJBs.
If there's an "advantage" to using EJBs, I'd say that it would depend on the skills of your team. If you have no Spring expertise, and lots of EJB experience, then maybe sticking with EJB 3.0 is a good move.
App servers written to support the EJB standard can, in theory, be ported from one compliant Java EE app server to another. But that means staying away from any and all vendor-specific extensions that lock you in to one vendor.
Spring ports easily between app servers (e.g., WebLogic, Tomcat, JBOSS, etc.) because it doesn't depend on them.
However, you are locked into Spring.
Spring encourages good OO design practices (e.g., interfaces, layers, separation of concerns) that benefit any problem they touch, even if you decide to switch to Guice or another DI framework.
Update: This question and answer are five years old in 2014. It needs to be said that the world of programming and application development have changed a great deal in that time.
It's no longer just a choice between Java or C#, Spring or EJBs. With vert.x it's possible to eschew Java EE altogether. You can write highly scalable,
polyglot applications without an app server.
Update: It's Mar 2016 now. Spring Boot offers an even better way to write applications without Java EE app servers. You can create an executable JAR and run it on a JVM.
I wonder if Oracle will continue to support the Java EE spec. Web services have taken over for EJBs. The EJB solution is dead. (Just my opinion.)
First, let me say it clearly, I'm not saying you shouldn't use Spring but, because you are asking for some advantages, here are at least two of them:
EJB 3 is a standard while Spring is not (it's a de facto standard but that's not the same thing) and this won't change in the foreseeable future. Although you can use the Spring framework with any application server, Spring applications are locked into both Spring itself and the specific services you choose to integrate in Spring.
The Spring framework sits on top of the application servers and service libraries. Service integration code (e.g. data access templates) resides in the framework and is exposed to the application developers. In contrast, the EJB 3 framework is integrated into the application server and the service integration code is encapsulated behind an interface. EJB 3 vendors can thus optimize the performance and developer experience by working at the application server level. For example, they can tie the JPA engine closely to JTA transaction management. Another example is clustering support which is transparent to EJB 3 developers.
EJB 3 is not perfect though, it is still lacking some features (e.g. injection of non managed components like simple POJOs).
Pascal's points are valid. There are, however, the following in favour of Spring.
EJB specification is actually a bit loose, and therefore different behaviours can be observed with different application servers. This will not be true for the most cases, of course, but I've had such a problem for some "dark corners".
Spring has a lot of extra goodies, like spring-test, AOP, MVC, JSF integration, etc. EJB has some of those (interceptors, for example), but in my opinion they are not that much developed.
In conclusion, it depends mainly on your exact case.
Spring is meant to complement EJB, not to replace it. Spring is a layer on top of EJB. As we know, coding of EJB is done using API, which means we have to implement everything in APIs using the Spring framework. We can create boiler-plate code, then just take that plate, add some stuff to it, then everything's done. Internally Spring is connected with EJB -- Spring wouldn't exist without EJB.
The main advantage of using Spring is that there is no coupling at all between classes.