We are building software in java, and are new to it. I confused about JPA.
Normally in MVC pattern, SQL queries are hidden in model. And controller can't access
the db directly.
When I use JPA, should model retrieve JPA object to controller? If yes, then controller has access to db, and this is against to pattern?
JPA is just an abstraction between your Domain Model Object and SQL (your JPA implementation like Hibernate etc. creates all the SQL queries for you).
The controller will not even know which database JPA uses at all. If you want a simpler application architecture your controller can use the JPA features directly. Other architecture use a Data Acces Object layer (where these objects provide methods like List getAllThingsBetween(Date from, Date to)) between your controller and JPA, so that the controller won't even know, that you are using JPA.
Related
Im not sure if i can use Spring Data JDBC also for complex models. My doubts arise especially cause in the Spring Data JDBC (3.0) documentation is written:
"There is a simple model of how to map entities to tables. It probably only works for rather simple cases. If you do not like that, you should code your own strategy. Spring Data JDBC offers only very limited support for customizing the strategy with annotations." https://docs.spring.io/spring-data/jdbc/docs/3.0.0/reference/html/#jdbc.why
I was expecting Spring Data JDBC is also working for more complex cases.
The limitations that rise from this simple model affect mostly legacy projects where you have a database that you maybe can't even change.
Spring Data JDBC is not intended to map an arbitrary database model to an arbitrary Java domain model, but to use a Domain Driven Design approach and construct the database accordingly.
But even in the cases where you hit the limitations of Spring Data JDBC you can always fall back on Springs JdbcTemplate without any conflict with the rest of your model which gets persisted by Spring Data JDBC.
The same is not true for JPA. Of course you can use JdbcTemplate with JPA as well, but you now have to very different approaches to persistence in your application which can and will interact in interesting ways due to JPA caching and dirty checking.
I therefore think Spring Data JDBC is an excellent choice for large application and complex models.
It's limitations will push you in the direction of better defined smaller modules and less complex models.
So there are two ways to persist an entity:
Using Hibernate's session factory where we get the current session and call save(), get(), update() methods.
Extending JPA's repository interfaces
I have the following questions:
How are these two methods different in the context of using Hibernate. As far as I understand, Hibernate is an implementation of JPA API. So when I say I want to use Hibernate, does it mean that I can use both of the above methods?
What is the preferred way of the two based on convenience, flexibility and optimisation?
JPA repository behind the scenes uses Hibernate or JPA APIs to implement its functionality and tries to "abstract" it or provide convenience methods on top of it. You don't have to use JPA repositories though, and can always switch to the Hibernate or JPA APIs when needed. Think though, if you really gain any benefit by using the Spring Data JPA repository concept.
I'm studying Spring boot, and i have create several entity, my problem now is to retrieve the data from controller to save it on db.
Surfing on the web I have learned that i have to use JPARepositery or CrudRepositery in this way:
An example with User entity
public interface UserRepository extends CrudRepository<User, Integer> {
}
and to save
User user = new User();
userRepository.save(user);
But if I have many entities, Do I need to create a repository for each entity?
I have read about Session, FactorySession and Transaction they are compatible with Spring boot? How it works? and #Transactional tag how it works?
Thanks in advance
Yes, usually you need to create one Repository per Entity. This is also a good practice because you are placing operations and queries related to the same Entity in the same Repository.
Yes, you can obtain a Session and a FactorySession object (Hibernate), but I would advice you against using Hibernate directy. Instead, it is better to use Spring Data or JPA mechanisms to access your database (just as you do using a Repository). The reason is because Hibernate is an implementation of the JPA standard and today we use JPA to access databases (because it masks the exact implementation of the ORM). This way you can later (potentially) replace Hibernate with another JPA implementation (such as EclipseLink) without the need to change your code (in theory). In most projects you will find Hibernate being used, however.
Yes, Transaction is a Spring annotation and an important database transaction mechanism in Spring Boot, too.
By default Spring Data Repositories process database Entities. Please, suggest the standard approach of getting same functionality with Spring Data framework, which allows you operating on your Business Domain Objects (DTO) instead of Entities, and encapsulates all DTO to/from Entity mappings.
My current obvious options are:
Additional "proxy-wrapper" where all methods have same names as in Spring Repository but accept and return DTO types and encapsulate conversions(mappings).
Some clever implementation of previous option using AOP with less boilerplate code.
Both options seem pretty awkward to me for such a standard task. So, I assume I am jut missing something here.
When developing with MVC with an ORM
I dont like the idea that the ORM will make changes in my DB.
My application is a data driven application and the DB is the the first thing i created.
Isn't that an overhead to maintain the data scheme both in the model and in the DB?
How do i manage it?
Any ORM that is more suitable to this kind of work method?
I dont like the idea that the ORM will make changes in my DB
ORM don't have to make any changes in your database structure. If you have existing database you can simply use it without requiring any automated changes.
Isn't that an overhead to maintain the data scheme both in the model and in the DB?
How do you want to present your data in MVC? Are you going to use classes representing your data from the database? If yes then you have a reason why ORM exists. ORM maps relational data from database to classes = it loads them for you and persists them for you (= you don't have to deal with database access and SQL). If you are going to use object oriented strongly typed approach then ORM will not be overhead for you.
If you are not going to use such approach you don't have to use MVC. Just use ASP.NET with SQL data sources or ASP.NET dynamic data.
Any ORM that is more suitable to this kind of work method?
You have no special method.
Almost every ORM has some support tools or extensions which allows you creating basic mapping and sometimes also classes from existing database. In EF you will simply add Entity Data model to your project and in wizard selects tables you want in your application.
Sure the last paragraph was simplified. Each ORM has learning curve and its specialties so it will not be so "simple".
For .NET 4 Entity Framework, the tooling let's you go both directions; generate a database from a model and generate a model from a database. These features give you flexibility when implementing your change management protocols. I'm not sure what options are available for NHibernate.
Entity Framework references:
http://msdn.microsoft.com/en-us/library/bb386876.aspx
http://msdn.microsoft.com/en-us/library/bb399249.aspx
http://www.simple-talk.com/dotnet/.net-framework/entity-framework-4460---learn-to-create-databases-from-the-model/
A Stackoverflow comparison of the two:
Deciding between NHibernate vs Entity Framework?