Spring MVC Reviews

With Spring MVC, I have only developed things based on problems. Spring MVC follows monolithic architectures, and it also includes monorepo. Spring MVC takes care of the implementation of controllers along with areas like controller class and service class. Spring MVC allows me to work with REST APIs, meaning it is an API-based product. Spring MVC basically supports REST API, along with the components and features. With Spring MVC, there is no need to write a lot of code as it supports the boilerplate code. A lot of annotations are used in Spring MVC, and it directly fetches what is required from the package. A user need not rely on an external package as the product automatically fetches what is required from the annotations used in Spring MVC, which makes it much more reliable and faster.

The best feature of Spring MVC is its auto-configuration capabilities. A user need not configure anything in the product as it offers configuration files to set profiling and guide users with what they need to connect for development, staging, or production. The auto-configuration is one of the best components of the solution.

In the future, I expect the solution to offer and include a lot of packages so that it can be configured more easily or the speed level increases, thereby helping it overcome its shortcomings.

I have been using Spring MVC for two years. I don't remember the version of the solution since I worked on it two months ago. My company is a partnership with Spring MVC.

Stability-wise, I rate the solution a nine out of ten.

Scalability-wise, I rate the solution a nine out of ten.

The Java team in our company uses the solution. I don't know of any other teams in our company that use the solution. Then there are other teams in our company, like the SAP team, that use some other tools. Based on the different projects in our company, there are different teams in our organization. Java team uses Spring MVC as CodeJava.net develops applications. Java team uses the product in our company.

I have not faced any issues with the technical support team of the product since it is easy to install, especially since the steps involved in the installation process are very familiar to those in our company who deal with the product's installation phase.

I have experience with CodeJava.net, after which I started to use Spring MVC. To use Spring MVC, I had to learn to install STS.

The initial setup phase of Spring MVC is easy if users install STS, an application available for free, in their environments. In Spring MVC, a user downloads any extension from the marketplace, and it also allows users to extend features that are supported in the current applications.

The solution is deployed in our company's IT environment with the help of Jenkins. The solution is deployed in the cloud.

The solution can be deployed in a minute or two. The solution can be deployed for the whole project in two to three minutes.

I think a lot of organizations that deal with different projects use Spring MVC since it provides them with good features. Most of the projects that companies deal with are cloud-based ones, where Spring MVC plays an important role. Spring MVC is reliable and faster than other tools for developing any kind of application.

I rate the overall solution a nine and a half out of ten.

We mainly use the solution to create microservices and functional services as rest services, which expose services at rest. In case there are things to orchestrate or to implement some flows, we can use other sub-projects like Data Flow, but Spring MVC's main use case is to explore capabilities to rest services so they can be used by the upper layer, which is the frontend.

It's an enterprise platform that's widely adopted. The platform has a large community, and you'll easily get support. Spring has extensive support for security because of frequent updates.

I've used the solution for more than ten years.

Spring MVC is one of the most stable frameworks.

Depending on the case, the initial setup can be easy when building services. If you want to set up something quickly, you have Spring Initializr, which can quickly set up an application using modules.

Effectively, deployment is a matter of minutes when deploying microservices. But for end-to-end deployments, you might have to create the services or provision the dependent services to be available for the service itself.

The solution is free.

I did not have to ask for support because Spring has such a large community, and I always found solutions from different blogs. Besides, I used plain Java before getting acquainted with Spring Framework. Other MVC-equivalent languages, such as PHP, have the same principles. Spring Framework is just a different language.

I rate Spring MVC a ten out of ten.

Advising others to use Spring MVC depends on context because if you were part of a medium or large project, you would use an enterprise or widely adopted framework. If it's a medium or small project, you might use PHP or another similar framework like Laravel or Lumen.

We are using Spring MVC based on our business problem statements.

One of the most valuble features for our business is the bootstrap which allows our developers to save time when developing code. Additionally, it has a built-in library that is useful.

The most valuable features of Spring MVC are the modules, such as Spring Admin. All the Spring solutions work well together and are simple to maintain, such as the load balancing on the client side.

The documentation for Spring MVC could improve.

In a new release of the solution, it would be helpful to have other built-in functionality to reduce our need to see other third-party solutions.

I have been using Spring MVC for approximately six years.

I rate the stability of Spring MVC a ten out of ten.

The scalability of Spring MVC depends on the infrastructure it is deployed in. If the infrastructure is scalable then the solution is.

We use the online community for support.

The initial setup of Spring MVC is straightforward. However, the difficulty depends on the company and pipeline involved.

We are using the open-source version of the solution.

I would advise others to use Spring MVC because if they understand this solution other solutions will be easier to understand in the future. 

I rate Spring MVC a nine out of ten.

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. 

I work for a financial institution that has a payment app in Pakistan. I can't be specific about how we use Spring MVC, but it is generally used for microservices.  

Spring MVC is fast and reliable. 

I have used Spring MVC for two and a half years. 

I rate Spring MVC eight out of 10 for stability. The solution is flawless, but we've had issues with our service provider. 

Scalability is a core feature of the Spring framework. It is more scalable than competing solutions. We have 14.5 million active end-users. 

MVC is a user-friendly cloud-based platform, so it was easy to set up. It's plug-and-play. Our DevOps was responsible for deployment. It has about five to 10 people. DevOps created the pipeline in Jenkins on which we deploy our modules   I was involved in staging the solution for production. We used Jenkins for that. 

The time needed for deployment depends on the size of your module and the development environment module size actually. Adding more modules takes about 10 to 15 minutes each. It would be nice if they could reduce that part. The deployment time is a little high.

I rate Spring MVC nine out of 10. I recently recommended the solution to a friend in Pakistan who founded a digital ledger startup. I suggested using the Spring Fabric. 

I use the solution to write APIs.

Spring MVC has provided me with a simple way to access my solution using a layered pattern.

The most valuable feature is simplicity. I can easily configure everything using the java notations and also write APIs with the solution.

I have recently had problems with the changes that were made using Spring Security. I use this model to make my APIs communicate with the front pages using JW Token. Now after the changes, I find it more difficult to do because it's not easy or inherent anymore. I would like to be able to make my APIs communicate with the front pages using JW Token easily again. 

I have been using the solution for five years.

The solution is stable.

The solution is scalable.

The technical support team is good and we also have access to the Spring Boot community.

I previously used JavaServer Faces and switched to Spring MVC for simplicity.

The initial setup is very easy using Spring boot. I give the ease of deployment a ten out of ten. The deployment took around five minutes and required three specialists.

The implementation was completed in-house.

I give the solution a nine out of ten.

Five programmers are required for the maintenance of the solution.

For new users, I advise them to start with Spring Boot first before using Spring MVC.

We use this solution for creating web applications, and for linking our UI with the backend of the system.

We appreciate that this product is really easy to integrate with third-party UI services.

This solution is also very straightforward for new users wishing to create items.

We would like the deployment of this solution to be easier as, at present, it is quite complicated.

We have been using this solution for five to six years.

We have found this to be a stable solution, and have not experienced any performance issues during our time using it.

The initial setup of this solution is very straightforward, and it is easy to integrate with our existing environment. However, deploying the solution can be complicated unless the native tool for this is being used.

This is an open-source solution, so there are no license costs involved with using it.

We would recommend that organizations ensure they have the native deployment tool available when implementing the solution.

We would rate this solution a nine out of ten.

In my organization, I belong to the software development department as part of the Java application team (comprising 20-25 people) and we use various tools related to Java development, including Spring MVC, in our work. Our primary use of Spring involves the development of web applications which are accessed through a browser.

The Spring framework has many modules that we use for our in-house development and each of them are integrated with each other. For example, we use Spring Hibernate integration as well as Spring JPA, among others. It's not a one-size-fits-all solution that Spring provides in the sense that we have to use several additional modules under the Spring umbrella.

We are not currently using the latest version of Spring even for newer applications due to the limitations imposed by the various platforms that we run. Some versions of Spring are only supported by certain versions of Java, and we also have legacy applications which require the use of older versions.

As for our infrastructure, everything is private and we are not on the cloud right now.

When we shifted from our legacy frameworks to the Spring framework, we discovered that Spring definitely made our development easier. One good example is that there is a lot of boiler plate code available that you don't have to write from scratch, making the development of web applications a much simpler process.

The newer versions of Spring MVC have released a lot of features that we are not using right now because, in many cases, we are limited to running older versions. As such, it would be nice if Spring were to improve support for upgrading to newer versions, especially for legacy applications.

We have been using Spring MVC for almost ten years.

It's a very stable solution. 

It's highly scalable.

Spring has excellent community support, not least because it's an open source framework. Its community is very vibrant and the software is used by a large number of developers. So for almost all the issues you might encounter, it's easy to find a solution on the Internet.

As compared to other frameworks, Spring is a moderate level framework and the deployment is not dependent on Spring itself, but rather it is dependent on the platform that you are using.

The main factors for setting up Spring MVC are how we go about packaging our application and where we intend to deploy it. By itself, Spring MVC is not part of the deployment process for our applications. It's a development framework and not a deployment framework, and so the deployment depends on which platform we use. Currently, we are using the Oracle WebLogic platform for deployment, and our deployment model is a very formal process. For local development and deployment, we deploy it ourselves in-house, but for deployments on staging or production servers, it is done by a different team and they take their own time and use their own methods to deploy Spring. 

Spring MVC is open source and free. 

Speaking from our own experience, Spring MVC has been one of the easiest frameworks to adopt. This is largely because Spring is based on the same MVC pattern as our legacy approaches to web application development and it has been a natural progression for us.

Before adopting anything, you first need to know your requirements and then you need to read up about it (e.g. check the Internet). The same applies with Spring MVC. You should only adopt it if it suits your requirements. However, if you do decide to go with Spring, I can assure you that you won't regret it. It's a very good framework. 

I would rate Spring MVC a nine out of ten.

The solution is primarily used for web services such as monolithic applications, like C applications which have already been running for a very long time.

The solution is stable and reliable. 

Developing web applications are quite easy there.

The solution is open-source and free to use.

The scalability is limited. 

The initial setup could be more straightforward. 

I've been using the solution for five years. 

We have a bit of a problem with scalability. That's why when we moved to MicroSys Architecture - it adds more value.

At this point, every few people are actually using the solution in our organization at this point. I'm not sure if there are any real plans to increase usage at this point in time. 

I've never contacted technical support. Therefore, I cannot rate how helpful their services are. 

We did not use different Java Frameworks before MVC.

The initial setup could be more straightforward. It's not very easy to accomplish a deployment. It took a very long time to deploy everything.

Spring is actually open-source. Only whatever the new Java versions coming out which are higher than Java 11 would need premium support, which costs money.

I'm not sure which version of the solution I'm using. 

I would not recommend MVC. Rather, I would recommend the use of Spring Boot as Spring Boot also supports all the web services and has even more additional features. That, and it is easy to use.

I'd rate MVC at a six out of ten.

We use the solution for the development of our web applications.

The solution could provide faster performance. Also, its framework must be more accessible. In addition, its native image support needs improvement.

I rate the solution's stability an eight or nine.

I rate the solution's scalability an eight out of ten. It depends on the way you develop the application.

The solution provides the best documentation for technical support. Also, we refer to online portals in case of queries.

Positive

I rate the solution's initial setup process a seven out of ten. My team includes around 30 to 40 executives, including managers, developers, and consultants involved in the deployment. It takes about two years to complete.

It is an open-source solution.

The solution is user-friendly and provides good documentation as well. I rate it an eight out of ten.