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 7 years ago.
Improve this question
I have used hibernate in my java project where I have used Spring MVC.
I avoided SPRING HIBERNATE because it seemed that it was making my code very tightly coupled. Now, even if I move the app to struts, my service layer would work fine (because I have used the core hibernate , it is not the one that spring provides).
I would like some experienced developer to answer this:
What is the reason of using spring hibernate? I know it provides a number of features but there is a trade off as it really makes your code tightly coupled, you can't re-use the services any where else since they would work based on spring's hibernate api
Spring having 7 different modules each are independent you can use anyone of them or multiple
The core container
Spring context
Spring AOP
Spring DAO
Spring ORM
Spring Web module
Spring MVC framework
you want to know about the ORM integration believe me it doesn't make any tight coupling with your service layer
you can use strut mvc at the same time on service layer spring-orm + hibernate there is no tight coupling, more over spring is providing transaction mgt. hibernatetemplate support, you need not to take care of session and transaction mgt and of course easy integration and configuration.
According to my experience Spring-Hibernate provides:
A template to make 'easy' its configuration
The persistence engine can be used as a dependency, so you can change it whenever you want without modify JPA annotations in your model classes
It's supposed to be much more efficient managing XA transactions
And nothing else ...
well complex question, i could answer it with another question :
What is the reason of using hibernate? I know it provides a number of features but there is a trade off as it really makes your code tightly couple, you can't re-use the services any where else since they would work based on hibernate api.
Why not using direct JDBC and SQL ?
To be more productive on the question : choosing a framework always come with a trade off : being coupled with the framework.
So either the features provided by the framework be worth to pay the trade off or not.
Related
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 2 years ago.
Improve this question
I recently started reading a book that explains in more detail the manipulation of databases, in terms of the relationships between them, especially. The problem is that this book is a bit old, from 2014. So I come with the following questions, to which you can clarify, please:
In the book we use Dao, Dto and Service pattern, but we can't use JPA, Spring Boot Repository or other new technologies to "replace" the old implementation that the book presents?
If so, can you give me an alternative to the code below, and how does it work? What could I improve, what could I give up, what should be completed, what should I learn, please!
Book divide the implementations of an Application in 2 teams:
UserInterface (Data Transfer Object of the entity, singleton in Memory DB and Controller as Mock Service and view)
Development Team (with creating the Entity and testing using TDD, creating DAO for that Entity, Business Service Tier and Presentation Tier
So, I can change this way of creating and manipulating the applications and Databases, if yes, how, and why? What should I use, how should I do it?
This is the git of the book I'm currently reading: https://github.com/Spring-Hibernate-Book/spring-hibernate-datamodeling-tdd-rest/tree/master/Spring-OODD/src
As far as division of labor, the concept of having a separate team work on the controller layer seems antiquated. It could be that the single-page-UI has its own team, but many places prefer that the same people work on everything for a feature front to back, in order to reduce opportunities for communication problems between teams.
The extent to which you need DTOs should be up to the developer's discretion. It used to be a practice to routinely copy all entities into DTOs to avoid issues like lazy-loading in the UI. If you are building a single-page application where you're passing JSON to the UI that isn't an issue. The single-page application architecture provides better separation between UI concerns, making DTOs less necessary in most cases.
For the rest of this the concepts should map over. A Spring JPA repository has the same function as a data access object, it just provides more of the implementation for you. The biggest change associated with the Hibernate mappings is to use JPA annotations instead. Services haven’t changed.
TLDR
things that have changed:
single-page applications have replaced serverside approaches like JSPs
standardizing on JPA instead of Hibernate
configuration classes, no application context XML anymore
profiles
focus on microservices vs. monoliths
more batteries-included (h2 by default, deployable jars, convention over config)
things that haven't changed:
general layering scheme of controllers calling services calling data access
Hibernate mapping strategies and general ORM issues
Spring transaction support
general Spring programming model with beans, DI, AOP
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 4 years ago.
Improve this question
In our team we're having a bit of a discussion while developing a fairly straightforward Spring Boot app. Because we wanted to clearly separate concerns, we have modularized (Maven modules) our system into three modules:
Service: has the Spring Boot dependency, depends on Model & Repository
Model: only has the domain classes and 'service' classes (no Spring Boot dependency)
Repository: only has the JDBC access logic (depends on Model, no Spring Boot dependency)
I've done a few Spring Boot projects before and this is the first time I've set it up like this. I have particular concerns as to whether it makes sense to keep Spring Boot out of Repository because it will require us to do a lot of the wiring, like JDBC, jooq, liquibase, etc. manually in Service.
Has anyone got any advice about whether or not it makes sense to do it like this?
I think that this question might have opinion based answers. However... I think that this separation can lead to a development model that looks more like the old waterfall model rather than modern approaches. As microservices approaches teach, I think that it could be better to apply a vertical separation of concerns, modularizing the application in functional areas and not by abstraction level. Internally, each module should handle everything is related to its functional area.
I have particular concerns as to whether it makes sense to keep Spring Boot out of Repository because it will require us to do a lot of the wiring, like JDBC, jooq, liquibase, etc. manually in Service.
If you use correctly TDD frameworks this should not be an issue. I already work on multi-module Maven projects (Spring Boot) and I have never had issues about this, but obviously it depends on what you are doing in your projects.
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 7 years ago.
Improve this question
I'm starting a project, willing to use Struts2 and Hibernate.
Should I use the struts2-full-hibernate plugin, or integrate them differently ?
Searching on Internet confused me: is it the standard way to integrate them ? If not, which is the standard way ?
In a nutshell:
Choose a framework for the front-end (usually MVC, then Struts2, JSF2, Spring MVC, etc... you've already chosen Struts2. The standard (not necessarily the better nor the most used) in the Java EE 6+ stack is JSF2);
Choose a persistence manager:
the standard with Java EE 6+ is JPA 2.0 (JSR 317 - Java Persistence API). JPA are just annotations, you need a library implementing them; Hibernate can be used as JPA implementation. Hibernate is not the only JPA provider, but it is the most used one (not necessarily the best one), and hence the most standard. With this configuration, you can structure the application's layers by separating the presentation layer (Struts2 actions) from the persistence layer, where the CRUD is performed. The DAO layer is also not needed anymore because JPA's EntityManager is the dao itself.
You can otherwise use raw Hibernate with its proprietary annotations (or any other persistence manager), and in that case, with Struts2, you can use the (vintage?) Struts2-Full-Hibernate plugin. It simplifies some jobs, but force you to use the OSIV (Open-Session-In-View) (anti)pattern.
After having chosen the framework and the persistence manager, you need to chose a DI (Dependency Injection) manager. If you are using Java EE 6+, the standard is to use CDI (JSR 299 - Contexts and Dependency Injection). Before Java EE 6, or for nostalgic developers, Spring is still available. It's been the first library providing DI / IoC (Inversion of Control) when Java EE was lacking it.
Specifically, with Struts2 you can:
integrate CDI with the Struts2-CDI-plugin;
integrate Spring with the Struts2-Spring-plugin.
Conclusion
According to Java EE, the standard configuration with Struts2 (instead of JSF2) is:
Struts2
Java EE 6+ (CDI + JPA 2.x + EJB 3.x)
Hibernate 4.x
Struts2-CDI-plugin
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
I am new to JavaEE and Spring Framework. I am having difficulty in understanding how we can write application using Spring Framework only. I have read over the internet that the intention of Spring Framework was to make development of enterprise level application simpler as opposed to EJB development (mainly in EJB 2.x series).
With JavaEE we have many technologies like:
1) EJB
2) JCP
3) JTA
4) JPA and so on.
While reading Spring Framework, i started with Dependency injection, Spring AOP, Spring MVC (and others i am reading).
I have difficulty in understand as to how just using Spring DI / AOP / MVC can it make full-blown Enterprise application? I read from one of the posts that, for example, for transaction management, we can use Spring's own Transaction management or use JTA. I believe JTA is part of JavaEE, and if we eventually use JavaEE's technologies, then how spring eases life?
Any answers which would help me clear this is highly appreciated.
Spring consists in many different parts, and so does Java EE. Some of them are direct competitors, while for others, Spring provides an abstraction layer and/or Spring integration of Java EE components.
For example:
Spring MVC is built on top of servlets (which are part of Java EE), and it competes with JAX-RS and JSF
Spring core (IoC, AOP) competes with CDI and EJBs
The Spring transaction handling is just an abstraction layer on top of existing transactional mechanisms (JPA, Hibernate, JDBC or JTA)
Spring-data-JPA is an abstraction layer on top of JPA
Spring-JDBC is an abstraction layer on top of JDBC
So, for a typical webapp built with Spring, you will at least use come components of Java EE: servlets, maybe JDBC or JPA. If you need messaging and XA, you'll use JMS and JTA, but Spring will provide an integration layer. Regarding dependency injection, you won't need EJBs and CDI, because Spring has direct support for the same functionality.
First of all, define Enterprise application - AFAIK "Enterprise" in Java EE is just a marketing term.
JavaEE is a set of API's and a bunch (a big one) of standards/specifications for building scalable server-side applications in Java, thus allowing to create something big and complex - something that could be called "enterprise".
Spring is an application framework (some would say "THE framework") which integrates with J2EE.
You are a programmer, thus you are the one who makes
full-blown Enterprise application
from a set of components, offered by Java EE, Spring or whatnot.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have an existing J2EE enterprise application to which I need to add auditing, i.e. be able to record CRUD operations on several important domain types (Employee, AdministratorRights, etc.).
The application has a standard n-tier architecture:
Web interface
Business operations encapsulated within a mixture of stateless session beans and transactional POJOs (using Spring)
persistence is a mixture of direct JDBC (from within the business layer) and EJB 2.x BMP entity beans (I know, I know)
My question is: are there any standard patterns or (better still) frameworks/libraries specifically for adding auditing as a cross-cutting concern? I know AOP can be used to implement cross-cutting concerns in general; I want to know if there's something specifically aimed at auditing.
Maybe you should have a look at Audit4j that provides auditing of business functionality and has several options for configuration.
Another framework is JaVers that focues more on auditing low-level modification on persistence layer, which might match your case a bit better.
Both framework provide audit-specific functionalities that goes beyond plain AOP/Interceptors.
Right now I'm leaning towards using Spring AOP (using the "#AspectJ" style) to advise the business operations that are exposed to the web layer.
I'm going to go a bit against the grain here and suggest that you look at a lower-tier solution. We have a similar architecture in our application, and for our auditing we've gone with database-level audit triggers that track operations within the RDBMS. This can be done as fine- or coarse-grained as you like, you just have to identify the entities you'd like to track.
Now, this isn't an ideologically pure solution; it involves putting logic in the database that is arguably supposed to remain in the business tier, and I can't deny that this view has value, but in our case we have many independent application interacting with the data model, some written in C, some scripted, and others J2EE apps, and all of them have to be audited consistently.
There's possibly still some AOP work to be done here on the J2EE side, mind you; any method that updates the database at all may have to have some additional work done to tell the database which user is doing the work. We use database session variables to do this, but there are other solutions, of course.
Try an Aspect Oriented programming framework.
From Wikipedia "Aspect-oriented programming (AOP) is a programming paradigm that increases modularity by allowing the separation of cross-cutting concerns".
For all EJBs you can use EJB 3.0 Interceptors (This is something similar to Servlet filter) and another similar interceptor for Spring (not familiar with spring)
As you are using EJBs as well as Spring that may not cover the whole transactions. Another approach could be using a Front Controller however that requires some modification in the client side. Yet another approach could be using a Servlet Filter however that means implementing the domain logic in the presentation layer.
I would recommend the Front Controller in this case.
I've just learned about a new Spring project called Spring Data JPA that offers an AOP-based auditing feature. It's not GA yet, but it bears keeping an eye on.