I'm starting a new Java Web project using Spring and obviously I need data access in my application.
In previous applications I used JDBC or ORM modules of Spring framework to implement my data access layer, but some times ago I read about Spring Data project. I'm curious about it and I'd like to know the diffenrences between the two projects and understand if there are advantages passing from one approach to the other.
Spring data provides several functionalities:
Common functionality related to database applications - Defining a "repository" element (similar to DAO) with various functionalities, audit trail, etc.
JdbcTemplate like support for various NoSQL databases - MongoDB, Redis, Neo4J, and there are several community projects for other databases
High level functionality for JDBC (mostly Oracle) and JPA to reduce boilerplate code
Spring data also aims to save boilerplate code, as the repositories are defined as interfaces and the implementation is given by spring based on the method names.
Spring Data use JPA. it is also great for reducing the amount of boilerplate code that you need to write.
By writing the interfaces
E.g. table.findAll()
Its uses aspects to create the boilerplate code to select * from table
or table.findByName
it will implement the code to select by Name
have a look at this excellent tutorial http://www.petrikainulainen.net/spring-data-jpa-tutorial/
Related
Nowadays typical JAVA application can expose some JPA entities via REST easily. In that case in short there is e.g. persistence.xml where driver, database, etc are defined to access the database and persistence unit easily can be used in the application.
I am looking for something opposite. I.e. if somebody saw the solution where persistence relays on REST API?
Background of my question is the following.
There is an app written in some ancient technology and there is quite complex logic behind. I would like to build new JEE JPA (Eclipselink if possible) based application which could (at least for some time) use that complex logic in order to find and read data. My idea was to implement REST interface on top of old application and let the new one use REST queries in order to deal with the data. Since logic is complex I would like to avoid duplicating it and maintaining 2 branches of code in different technologies until I am fully prepared to move all stuff into modern technology.
Do you think it is possible?
You can design your Data Access Layer and the rest of your new application so that it doesn't care how the data is stored (no "bad" dependencies).
You would then need to create separate versions of the DAL, where one would fetch the data from the legacy REST app and one would use JPA. This will make it possible to start out being dependent on the legacy app, and part by part build the JPA DAL to retrieve data from a database.
I am trying to create web application that allow its users to create new forms and tables (many ERP applications have such feature). It is clear about generating and saving HTML forms and it is clear about generating new tables in database as well. But what about entities, e.g. Spring #Entity and #Repository classes.
One can try to compile then on the fly and save into the web application deployment directory, that should be possible. But is there need to update some kind of internal Spring registry of existing beans, repositories and controllers. Does Java JPA have such registry as well?
Is it possible to do such kind of thing? It is clear that it is possible to do this in php, e.g. to dynamically update yii framework application, because there is no compiled code (except, maybe, cached code) and with each new request the available paths are scanned anew. But how this happens in Enterprise Java and Spring applications?
Maybe I should look for Groovy Grails or Scala Play - they may be more dynamic languages.
More "object java storages" compatible with JPA (ObjectDB and Co) promise smoother, more natural migration with extra fields and classes. I haven't personal opinion.
EDIT: good perspective has, I think, philosophy ActiveRecord and similar. Few solutions in Java are ready. I have tried such solutions with partial success, but my project was not too dynamic (classes were stable) and we switched to clear JPA.
some ERP applications (in different languages f.e.C,Java.C#) have an idea "kernel class and additional fields", ie. Customer with all typical fields plus "Preffered color" (usually implemented in extra hidden tables). This is OK if they don't need new relations
Eclipselink has similar concept 'extra fields' in JPA area (not strict standard JPA but extension) https://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic
At project level, seems to be OK enter non-critical data
3 Ist hard to imagine create high count of dynamic important/central classes (tables) without radically redesigned application (proverbially version 2.0 ;) )
Sometimes I try stop and restart EMFactory with different Persistence Units (in Tomcat environment) with Hibernate and Eslipselink, but not use in production. Reset & start seems be ok, this is like rupture and new life of JPA engine. Its more like application 2.0 than small patch.
Creating multiple gemmini table sets (for different companies in the same database) is good in Hibertate and Eslipselink (prefix before table name), few dedicated lines by start, normal clean JPA use. Tested, all OK.
Once again, adding single/few tables is poorly reworked in the community.
It is an interesting discussion to "glue" together common JPA modules (code+JPA), this is done often by OSGI programmers.
Theoretically so it has to module give your tables, strongly connected in the same PU.
At the ERP application level it can be anything from "add CRM module" to "kernel + sales".
I'm an interested spectator, but i have not seen any success.
If you look in the google integrate persistence unit from parts, composite persistence unit, many programers try to reach such target.
It is like a fishing rod rather than fish (as the old adage goes).
Persistence Unit conception isn't friendly for such ideas (and is blocked in standard JPA).
What are the main differences between Hibernate and Spring Data JPA?
When should we not use Hibernate or Spring Data JPA?
Also, when may Spring JDBC template perform better than Hibernate and Spring Data JPA?
Hibernate is a JPA implementation, while Spring Data JPA is a JPA data access abstraction. Spring Data JPA cannot work without a JPA provider.
Spring Data offers a solution to the DDD Repository pattern or the legacy GenericDao custom implementations. It can also generate JPA queries on your behalf through method name conventions.
With Spring Data, you may use Hibernate, EclipseLink, or any other JPA provider. A very interesting benefit of using Spring or Java EE is that you can control transaction boundaries declaratively using the #Transactional annotation.
Spring JDBC is much more lightweight, and it's intended for native querying, and if you only intend to use JDBC alone, then you are better off using Spring JDBC to deal with the JDBC verbosity.
Therefore, Hibernate and Spring Data are complementary rather than competitors.
There are 3 different things we are using here :
JPA : Java persistence api which provide specification for persisting, reading, managing data from your java object to relations in database.
Hibernate: There are various provider which implement jpa. Hibernate is one of them. So we have other provider as well. But if using jpa with spring it allows you to switch to different providers in future.
Spring Data JPA : This is another layer on top of jpa which spring provide to make your life easy.
So lets understand how spring data jpa and spring + hibernate works-
Spring Data JPA:
Let's say you are using spring + hibernate for your application. Now you need to have dao interface and implementation where you will be writing crud operation using SessionFactory of hibernate. Let say you are writing dao class for Employee class, tomorrow in your application you might need to write similiar crud operation for any other entity. So there is lot of boilerplate code we can see here.
Now Spring data jpa allow us to define dao interfaces by extending its repositories(crudrepository, jparepository) so it provide you dao implementation at runtime. You don't need to write dao implementation anymore.Thats how spring data jpa makes your life easy.
I disagree SpringJPA makes live easy. Yes, it provides some classes and you can make some simple DAO fast, but in fact, it's all you can do.
If you want to do something more than findById() or save, you must go through hell:
no EntityManager access in org.springframework.data.repository classes (this is basic JPA class!)
own transaction management (hibernate transactions disallowed)
huge problems with more than one datasources configuration
no datasource pooling (HikariCP must be in use as third party library)
Why own transaction management is an disadvantage? Since Java 1.8 allows default methods into interfaces, Spring annotation based transactions, simple doesn't work.
Unfortunately, SpringJPA is based on reflections, and sometimes you need to point a method name or entity package into annotations (!). That's why any refactoring makes big crash.
Sadly, #Transactional works for primary DS only :( So, if you have more than one DataSources, remember - transactions works just for primary one :)
What are the main differences between Hibernate and Spring Data JPA?
Hibernate is JPA compatibile, SpringJPA Spring compatibile. Your HibernateJPA DAO can be used with JavaEE or Hibernate Standalone, when SpringJPA can be used within Spring - SpringBoot for example
When should we not use Hibernate or Spring Data JPA? Also, when may Spring JDBC template perform better than Hibernate / Spring Data JPA?
Use Spring JDBC only when you need to use much Joins or when you need to use Spring having multiple datasource connections. Generally, avoid JPA for Joins.
But my general advice, use fresh solution—Daobab (http://www.daobab.io).
Daobab is my Java and any JPA engine integrator, and I believe it will help much in your tasks :)
Spring Data is a convenience library on top of JPA that abstracts away many things and brings Spring magic (like it or not) to the persistence store access. It is primarily used for working with relational databases. In short, it allows you to declare interfaces that have methods like findByNameOrderByAge(String name); that will be parsed in runtime and converted into appropriate JPA queries.
Its placement atop of JPA makes its use tempting for:
Rookie developers who don't know SQL or know it badly. This is a
recipe for disaster but they can get away with it if the project is trivial.
Experienced engineers who know what they do and want to spindle up things
fast. This might be a viable strategy (but read further).
From my experience with Spring Data, its magic is too much (this is applicable to Spring in general). I started to use it heavily in one project and eventually hit several corner cases where I couldn't get the library out of my way and ended up with ugly workarounds. Later I read other users' complaints and realized that these issues are typical for Spring Data. For example, check this issue that led to hours of investigation/swearing:
public TourAccommodationRate createTourAccommodationRate(
#RequestBody TourAccommodationRate tourAccommodationRate
) {
if (tourAccommodationRate.getId() != null) {
throw new BadRequestException("id MUST NOT be specified in a body during entry creation");
}
// This is an ugly hack required for the Room slim model to work. The problem stems from the fact that
// when we send a child entity having the many-to-many (M:N) relation to the containing entity, its
// information is not fetched. As a result, we get NPEs when trying to access all but its Id in the
// code creating the corresponding slim model. By detaching the entity from the persistence context we
// force the ORM to re-fetch it from the database instead of taking it from the cache
tourAccommodationRateRepository.save(tourAccommodationRate);
entityManager.detach(tourAccommodationRate);
return tourAccommodationRateRepository.findOne(tourAccommodationRate.getId());
}
I ended up going lower level and started using JDBI - a nice library with just enough "magic" to save you from the boilerplate. With it, you have complete control over SQL queries and almost never have to fight the library.
If you prefer simplicity and more control on SQL queries then I would suggest going with Spring Data/ Spring JDBC.
Its good amount of learning curve in JPA and sometimes difficult to debug issues.
On the other hand, while you have full control over SQL, it becomes much easier to optimize query and improve performance. You can easily share your SQL with DBA or someone who has a better understanding of Database.
Hibernate is implementation of "JPA" which is a specification for Java objects in Database.
I would recommend to use w.r.t JPA as you can switch between different ORMS.
When you use JDBC then you need to use SQL Queries, so if you are proficient in SQL then go for JDBC.
I am trying to use the DAO pattern in my multiple web app projects. I have three different web applications and they share two different databases. Each databases have number of tables.
Now I am wondering how I can make my program modular by using best practice. I am thinking of making:
DAO project which have two factory class for each database, DAO interfaces for each tables and DTO for each tables.
Then in each web app project I am planning to write implementation code for DAO interface and necessary utility class for getting and closing the connections.
Is this approach good? The doubt/problem i am having is with this design if I am going to ship any one of the project I have to ship DAO project also but that will contain unnecessary info about other databases.
Or will it be good to attach all necessary DAO in web app itself? If so then I have to write same DAO ode for each web app.
Hope anyone can provide me the clear path for this DB connection using DAO pattern.
In general, you're headed in the right direction by separating your concerns.
You mention the multiple web apps rely on the two databases. Does each web app rely on both databases? If so, I'd consider creating a single DAO project to encapsulate all the data access logic.
If it's more a mix and match (web app a uses db a, web app b uses db b, web app c uses a and b), I'd consider having two DAO projects, one per database, unless there's a lot of combined logic - that is, when an app uses both databases, it's doing joins between them [yes, I have had projects that do this].
I'd also recommend looking at an Object/Relational Mapping (ORM) framework such as Hibernate and/or a Dependency Injection framework such as Spring, which can help simplify the process of separating the various projects and then using them together.
You're clearly planning a pretty ambitious project, so taking advantage of existing frameworks to minimize recreating the wheel will let you focus on your specific problem domain.
Use JPA to access DB. If not possible then use JdbcTemplate (Spring)
EntityManager (JPA) is a kind of a DAO
DAO only where it makes sense (e.g. complex, reusable logic using an EntityManager)
Use pooled connections/ DataSources
DTO are usually only needed if your objects need to leave the JVM (e.g. remote EJB services, web services,...)
use EJBs for container-managed transactions
consider the Gateway pattern (a stateful session bean and an extended persistence context, see "Real World Java EE Patterns – Rethinking Best Practices" by Adam Bien) and just return the attached entity.
I'm currently rebuilding an existing PHP application using Java. I therefore have an existing frontend GUI and an existing database schema that I'm working with.
Here is the technology stack I'm working towards:
jQuery, client-side
Wicket, front-end
Spring, ???
Hibernate, ORM
MySQL, database
Before reading about Spring in both Wicket In Action and the Hibernate documentation, I envisioned wiring the two together through my own business logic. I have experience with JBoss Seam, but am told that Spring is hardly comparable (although the documentation suggests otherwise, IMO). Short of adding a book about Spring to my reading list (I haven't found an appropriate one with good reviews yet), I'm at a loss.
What benefit(s) will Spring provide in this technology stack?
Subjective & optional follow up question: what reference material (book, website, etc) will get me started with the portion of Spring 3 I may utilize?
First, you can make your web application without Spring. But Spring will greatly facilitate things. Spring framework is a lightweight, non-invasive. Spring is like a kind of conductor. Among other things Spring helps you in:
To keep your objects loosely coupled. This will make your application more flexible and open to future changes
Powerful support for transactions through the AOP (Aspect Oriented Programming).
Object-relational mapping (ORM) integration module. Spring doesn’t attempt to implement its own ORM solution, but does provide hooks into several popular ORM frameworks, including Hibernate, Java Persistence API, Java Data Objects, and iBATIS SQL Maps. Spring’s Transaction management supports each of these ORM frameworks as well as JDBC.
The Spring MVC framework. Even though Spring integrates with several popular MVC frameworks, it also comes with its own very capable MVC framework that promotes Spring’s loosely coupled techniques in the web layer of an application.
A good book about Spring: Pro Spring
Spring, as noted in this review is non-invasive. It just wires your application components. And provides useful classes that make using other frameworks easier (JMS, JPA, etc). Spring doesn't force you to use its classes or interfaces anywhere.
What it handles is the creation of your components (objects), so that you can refer to a class' dependencies, without instantiating them. I.e. you say what your class needs, not how it is obtaining it. This makes the application very flexible.
That's in short - for more, read the linked article. It's not about the latest version, but that doesn't matter.
In addition to dependency injection, Spring offers features like declarative transaction management, simple integration with ORM, aspect-oriented programming support and many other nice things.
For documentation see Spring reference: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html
#Dolph, in the simplest term, think of Spring as your application framework at the highest degree. This "framework" provides several "component buckets" where you can easily plug in different types of implementations. For example, for ORM, you may choose to use Hibernate over JPA or TopLink, for front end, you may choose Wicket over Struts or SpringMVC, and so forth.
The whole beauty of this (besides all the goodies stated in other posts) is it allows you easily swap out any of these implementations easily in the future. So, you can essentially rip out Hibernate one day and replace with TopLink, and it will never cause ripple effect to other components.
Another beauty of using Spring is your code becomes less clutter and has loose dependencies with other classes because you spend less time creating new objects yourself, Spring handles that for you. That said, you will quickly realize how easy for you to test your code because your API to be tested becomes very atomic. This is one primary reason why folks get discouraged in writing testcases, because they quickly realize that in order for them to test one API, they have to construct whole lot of things just to test that. Because of that, the whole process is brittle, imagine if you change that API, you need to reconstruct everything before testing it again.
Pro Spring book is good, mentioned by #JLBarros. I like Spring in Action very much. It is very very easy to read when I first got started with Spring. This is probably one reference book that I read from skin to skin.