Spring MVC is a Java web framework built on the Servlet API and has been included in the Spring Framework from the very beginning. It handles web applications that use server-rendered HTML user interface, REST APIs, and much more. The documentation includes Spring MVC, View Technologies, CORS Support, and WebSocket Support.
| Title | Rating | Mindshare | Recommending | |
|---|---|---|---|---|
| Spring Boot | 4.2 | 41.5% | 95% | 38 interviewsAdd to research |
| Jakarta EE | 3.7 | 16.9% | 66% | 3 interviewsAdd to research |
For baseline information and compatibility with Servlet container and Java EE version ranges please visit the Spring Framework Wiki.
Spring MVC was previously known as Spring by Pivotal, Spring, Spring Framework.
EMC, Aridhia, CoreLogic, CenturyLink, Humana, Purdue University, Tampon Run, ArtsPool, Charity Water, Center for ReSource Conservation, Manos Teatrales
We primarily use the solution to create APIs. Basically, you have a SQL query, and you write Java code to create a single API link based on that. And then, that API gets connected to JasperReports Library using an adapter. You create reports based on that.
The company wanted to create an API hub. And then whatever they needed to access, they wanted to access it from that central API to be able to do anything with the data. That way, when an API was required, they used Spring MVC to be able to create that API. On the back-end side, it was Oracle 11G that needed to retrieve the data for the specific API.
MVC would have been beneficial if, at all, we needed to, let's say, add any customizers on top of it. For example, if at all you need is some sort of logic to be applied to a specific report, which is not available in, let's say, JasperReports Library.
I could write this MVC code or could use a scriptlet, which is a feature in the JasperReports engine, to be able to write the classes on top of it. Or I would use an MVC model to pass those values to be able to get the results based on the requirements.
There are a lot of dependencies during the initial setup.
I didn't like to create APIs. I would have definitely directly connected to the Oracle 11G and created reports based on that. However, obviously, the setup was already there. I did a POC based on it, and I asked them not to actually use this API to directly connect to the database, Oracle 11G, to be able to create the reports. In the end, that wasn't my decision. It wasn't up to me. I would prefer to use a database directly connecting to the report writer and creating reports based on that. The performance is better that way. When you create APIs on top of it, you run into many issues, which I've seen when migrating reports from Business Objects to the JasperReports engine.
It's a stable product.
The solution can scale.
I saw some error messages coming up when they were getting problems actually viewing all the reports. I looked at the error code, and I could see that they are using the S3 bucket to be able to save their flat files into it. It was on AWS.
I've used the solution over the last 12 months.
The stability is much better than it was before.
The first version, when I used Jaspersoft, basically was all Java code. Now, this model obviously basically makes the code quite clean.
Also, in terms of performance, it's much better since you only use those specific libraries which you want to use. You don't use the rest of them, which shouldn't be there in the first place. Basically, it's a lot better than before.
The solution is quite scalable. I'd give the scalability a four out of five in terms of ease of expansion.
We had eight to ten people working on the solution.
In terms of the initial setup, there were a lot of dependencies when I started doing it for the first time. I was thinking to myself that I could actually connect to the Oracle database, and do the same thing. For example, why do I need to create an API to be able to create those reports? However, that wasn't my decision. That's what happens in certain banks. And they don't give us the flexibility at times to make a decision. The decisions are made by upper management.
It's a bit difficult. I'd rate the implementation process two out of five in terms of ease of setup. When I created my first API, all I could think was that I'm starting all sorts of problems just to create an API for a specific SQL query.
The deployment used to take a while. Just deploying one API would take me half an hour to 45 minutes, including all the dependencies.
I'm not sure of the pricing I use MVC on my own whenever I need to use it. It's free for me. I don't know the pricing model since I wasn't there setting it up. I wasn't there to actually configure it in the first place. I don't know anything about the cost structure.
I am an end-user.
I'm not sure which version of the solution I'm using.
It is already a lot better than how it was before. I'd rate it eight out of ten understanding that it still needs improvements here and there.
