I went to an interview into a IT consultancy company last friday.
The Interviewer asked me about my project and what was my participation in it.
Suddenly he threw one question on hibernate. His question was as follows
"If i have an project which has been developed in an MVC architecture using Java EE environment, but using JDBC for Database interaction, how will i integrate Hibernate into it. I don't want to disturb the existing code, all the previous JDBC code should be intact. "
I told him that we an add all the features of hibernate in the existing code, as it only requires Config files, Entities thats it. The old code of JDBC may itself be using Datasourse for getting connection, the same datasourse can be looked up using JNDI to build a session factory in Hibernate, not a big deal.
But the interviewer was not happy with my answer, he needed some more explanation.
I was not able to impress him.
So can you please suggest what should be the probable answer for the above question.
Or at least give me one hint so that i can come to an answer.
I think he wanted answer like the following.
Typical application design requires layers separation. There are the following classic layers: web tier, business logic and DB. There is a thin layer named DAO (Data Access Objects) that is written in java and plays a role of "middleman" between business logic and DB. It sounds that this tier is implemented using plain JDBC.
So, there is not a problem to replace this and only this layer with Hibernate based one.
Now you can add more details about how you are configuring Hibernate and integrate it with the rest of your application.
Not an exact answer and you did not mention which framework your application use but if your application uses Spring framework, this my question and its answer's will be helpful to you but my question is reverse as I wanted to integrate jdbc with hibernate.
I think he was probably looking for you to explain how you might:
put Hibernate wrappers around existing SQL queries, or
create Hibernate bindings for legacy SQL tables, or
integrate Hibernate and classic JDBC using container-level transactions.
(It is clear that he was not asking about how you would replace the old JDBC code with Hibernate code ...)
But of course, you'd really need to ask him what knowledge / experience he was expecting you to demonstrate in answering the question.
Related
Currently I develop a project which was earlier supported by someone else and they used Hibernate. I want to use Spring JDBC template in this project because I'm unfamiliar with Hibernate.
Can one use both of them? Will be there conflicts if you use them both?
It's completely normal and I saw the situation in one of my previous project though I think you should stick to the technology which is already used in the project unless you have a very good reason(performance, for example).
Well, I will try to answer the questions you asked and one you should have asked.
Can one use both of them?
Yes, it is common to use Hibernate for most persistence classes and JDBC for only some of them
Will be there conflicts if you use them both?
No, provided you do not use both on same objects. If you did, you could easily get weird results due to cache inconsistencies
Is I am not good at Hibernate a valid reason to use Spring JDBC template for next developments in a project based on Hibernate ?
IMHO no unless it is a decision from the head maintainer to change technology. For future maintainance sake, you should try to stick to previous usages, unless a clear documented decision says that from now on this will be the new usage. But that also means that whenever you change a class using the older technology, you must wonder whether it is time to port it to the new one.
TL/DR: If you are working on a real world serious project that will be used in production, you'd better learn Hibernate. It is a state of the art largely used framework and it is worth learning it. If you are working on a private project, you are on your own.
Yes, you can do this. Sometimes for faster and better performance, people use JDBC template. If this is not the case, I will recommend you to use Hibernate as it is already implemented in the project.
For future study, please learn Spring Data JPA, it is very easy, need to configure your DB queries in an interface and Spring automatically creates an implementation of it.
Have a look –
Spring Data JPA
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
We have been using JDBC for a very long time in our web applications. The main reason we used it is because we have 100% control over the code, sql and fix things by our hands. Apart from that we used triggers inside the database, and the database is developed separately by DB experts.
However many now recommend using Hibernate so we also thought about using it. But, we found the below issues.
Hibernate cannot connect with an "Existing" database. It always try to create a one of its own.
Our database might access by same application which is in different platforms (cloud, server, VPS, Personal Computer). Hibernate can make problems because of its caching in this situation.
We never like to give the "table creating work" to the java code. We create tables manually, always.
We might have to use very long and complex SQL statements. Last time we used an statement with more than 150 lines, joining more than 20 tables. We doubt whether we will face troubles in this when it comes to Hibernate.
Our SQL code is nice and standard. Hibernate generated code seems to be bit dirty for us.
We always use MySQL. Never use any other DB.
The application we create require max security, related to medical. If at least one data record is leaked, we are done.
There are lot of foreign keys, Primary Keys, Composite Keys, Unique Keys etc etc in database. In forums, some complained that Hibernate messed with those.
We decided to try hibernate because some people claims, "Are you Software Engineers? You are using already dead JDBC !!. "
Considering these, please let me know whether the above points are actually true (as I said, I got to know them via googling, discussion etc) or not. And, what are the pros and cons of Hibernate VS Java JDBC?
Answering issues listed above:
1. Hibernate cannot connect with an "Existing" database. It always try to create a one of its own.
This is wrong. Hibernate can connect to an existing database, and it doesn't always try to recreate it. You just should turn of parameter like hbm2ddl. auto.
2. Our database might access by same application which is in different platforms (cloud, server, VPS, Personal Computer). Hibernate can make problems because of its caching in this situation.
Hibernate has an adjustable cache, so this is also not a problem.
3. We never like to give the "table creating work" to the java code. We create tables manually, always.
No problem. See p.1 above. Furthemore there are several convinient libraries for indirect table creation and update (e.g. liquibase) which can be used in couple with hibernate perfectly.
4. We might have to use very long and complex SQL statements. Last time we used an statement with more than 150 lines, joining more than 20 tables. We doubt whether we will face troubles in this when it comes to Hibernate.
You can always use direct JDBC calls and invoke native SQL queries via hibernate, if it is neeeded.
5. Our SQL code is nice and standard. Hibernate generated code seems to be bit dirty for us.
Again, if you have to invoke some logic complicated SQL code instead of hibernate auto-generated - you can do it.
6. We always use MySQL. Never use any other DB.
Not a problem at all. Hibernate has special MySQL dialect support: org.hibernate.dialect.MySQLDialect.
7. The application we create require max security, related to medical. If at least one data record is leaked, we are done.
Security issues aren't related to ORM techniques. Hibernate is just logical and convinient object-oriented layer between pure database JDBC calls and programmers tools. It doesn't influence somehow on common net security.
Hibernate is a great tool and you'll find plenty of documentation, books, and blog articles about it.
I will address all your concerns:
Hibernate cannot connect with an "Existing" database. It always tries to create one of its own.
Hibernate should use a separate database schema management procedure even for integration testing. You should use an incremental versioning tool like FlywayDB to manage your schema changes.
Our database might access by same application which is in different platforms (cloud, server, VPS, Personal Computer). Hibernate can make problems because of its caching in this situation.
You don't have to use the 2nd level cache, which uses 3rd party caching implementations. All caching solutions may break transactional consistency. The first level cache guarantees session-level repeatable reads and with the optimistic locking in place you can prevent lost updates.
We never like to give the "table creating work" to the java code. We create tables manually, always.
The DB should be separated from your ORM tool. That's a best practice anyway.
We might have to use very long and complex SQL statements. Last time we used an statement with more than 150 lines, joining more than 20 tables. We doubt whether we will face troubles in this when it comes to Hibernate.
Hibernate is great for write operations and for concurrency control. You still need to use native SQL for advanced queries (window functions, CTE). But Hibernate allows you to run native queries.
Our SQL code is nice and standard. Hibernate generated code seems to be bit dirty for us.
You don't need and you shouldn't probably use the hbmdll utility anyway.
We always use MySQL. Never use any other DB.
That's even better. You can therefore use advance native queries without caring for database portability issues.
The application we create require max security, related to medical. If at least one data record is leaked, we are done.
Hibernate doesn't prevent you from securing your database or the data access code. You can still use database security measures with Hibernate too. You can even use Jasypt to enable all sorts of security-related features:
advanced password hashing
two-way encryption
There are lot of foreign keys, Primary Keys, Composite Keys, Unique Keys etc etc in database. In forums, some complained that Hibernate messed with those.
All of those are supported by Hibernate. Aside from the JPA conventions, Hibernate also offers particular mapping for any exotic mapping.
We decided to try hibernate because some people claims, "Are you Software Engineers? You are using already dead JDBC !!. "
That's not the right argument for switching from a library you already master. If you think you can benefit from using Hibernate then that's the only compelling reason for switching from JDBC.
Using plain old JDBC, does not mean you are lacking in IT industry, rather Hibernate also uses JDBC in the underlying layer.
What advantages it gives us what we should look for.
1.) Cache Mechanism.
2.) Managing sessions, transactions etc.
3.) Reduce efforts in writing queries, more utilities of hibernate like Query API, Criteria API, HQL
The questions that you have raised are more or less covered in Hibernate docs.
Also there are lot more caching strategy available ehcache, infinispan, depends on the server we are deploying, JBOSS, Weblogic, Tomcat etc. ++ environment like cloud, distributed cache etc.
Hibernate still provides you with option of turning off automatically creating schema and pointing to the one create by you.
Here are the quick answers that I know
1) You can connect to an existing database. But yeah as stated here
If you don't have a solid object model, I'd say that Hibernate is a
terrible choice.
2) As you database is been accessed from different applications so you can maintain locks. On-the-other-hand you can trun-off caching as done here.
3) You can create tables manually and connect it using .hbm.xml file.
4) You can use any type of query in hibernate like simple SQL queries criteria.
5) You can directly use SQL code in Hibernate, if you want. Other option is to use criteria.
6) Hibernate is NOT DB specific. You can go for any Database and connect it with hibernate.
7) Using locks and giving rights in database you can maintain security.
8) Agreed that foreign keys are messy in Hibernate If You Donot Handle It Well. So Use OO approach and maintain cascades well, then Hibernate will be good choice.
New to Java EE6 and I'm trying to set up a JDBCRealm. Many of the examples suggest making the tables that hold user/group information by hand in SQL.
Is there a more standard "JPA" way of doing it though? The tables Glassfish expects don't fit with the kind of table structures you'll end up with if you use e.g. a OneToMany mapping (which is what I was hoping I could use).
I read Glassfish still uses JDBC to accomplish the JDBCRealm, which would explain why. And I came across this blog which suggests a way to do it with JPA.
http://www.codeproject.com/Articles/238779/J2EE-JDBC-based-authentication-with-JPA-Entities-i
But is there an 'official' way to do it with JPA? I want to make sure I follow best-practice to ensure I have a secure application.
Thanks
A few months ago i wanted to create my JDBC Realm with glassfish and i also had lots of doubts. I will try to explain you more or less how i did it using JPA.
Many of the examples suggest making the tables that hold user/group
information by hand in SQL
I disagree, if you are using JPA for other tasks related to persistence why would you make an exception when regarding to security. So JPA is a good idea. Copy/Pasting a chunk of SQL in your DB console is easy but better if you have entities that will automatically will always create those tables for you when you deploy your app.
The tutorial you are following is fine, i think there is no such think as a best practice.
I will give you some resources that i think will help you creating the JDBC realm.
Maybe you are interested in something a bit more simple, just to warm up, in that case have a look at this post:
http://javing.blogspot.in/2012/05/here-in-this-video-you-can-see-how-i.html
It talks about ROLE based security in glassfish, i think it can give you some tips.
If you want to know how to create the JDBC realm with JPA, follow this question i made time ago, at the end you will find the solution:
Glassfish 3 security - Form based authentication using a JDBC Realm
If you paste some code we could help you trouble shouting in case you get stuck.
There are technically two questions here, but are tightly coupled :)
I'm using Hibernate in a new project. It's a POS project.
It uses Oracle database.
We have decided to use Hibernate because the project is large, and because it provides (the most popular) ORM capabilities.
Spring is, for now, out of the question - the reason being: the project is a Swing client-server application, and it adds needless complexity. And, also, Spring is supposed to be very hungry on the hardware resources.
There is a possibility to throw away Hibernate, and to use JDBC. Why? The project requirement is precise database interaction. Meaning, we should have complete control over the connections, sessions and transactions(and, yes, going as low as unoptimized queries).
The first question is - what are your opinions on using the mentioned requrement?
The second question revolves around Hibernate.
We developed a simple Hibernate pilot project.
Another project requirement is - one database user / one connection per user / one session per user / transactions are flexibile(we can end them when we want, as sessions).
Multiple user can log in the application at the same time.
We achived something like that. To be precise, we achived the full described functionality without the multiple users requirement.
Now, looking at the available resources, I came to a conclusion that if we are to have multiple users on the database(on the same schema), we will end up using multiple SessionFactory, implementing a dynamic ConnectionProvider for new user connections. Why?
The users hashed passwords are in the database, so we need to dynamically add a user to the list of current users.
The second question is - can this be done a little easier, it seems weird that Hibernate doesn't support such configurations.
Thank you.
If you're pondering about weather to use Hibernate or JDBC, honestlly go for JDBC. If your domain model is not too complex, you don't really get a lot of advantages from using hibernate. On the other hand using JDBC will greatly improve performance, as you have better control on your queries, and you get A LOT less memory usage from not habing all the Hibernate overhead. Balance this my making an as detailed as possible first scetch of your model. If you're able to schetch it all from the start (no parts that are possible to change wildly in throughout the project), and if said model doesn't look to involved, JDBC will be your friend.
About your users and sessions there, I think you might be mistaking (tho it could just be me), but I don't think you need multiple SessionFactories to have multiple sessions. SessionFactory is a heavy object to initialize, but once you have one you can get multiple hibernate session objects from it which are lightweight.
As a final remark, if you truly stick with an ORM solution (for whatever reason), if possible chose EclipseLink JPA2 implementation. JPA2 has more features over hibernate and the Eclipselink implementation is less buggy then hibernate.
So, as far as Hibernate goes, I still dont know if the only way to dynamicaly change database users(change database connections) was to create multiple session factories, but I presume it is.
We have lowered our requriements, and decided to use Hibernate, use only one user on the database(one connection), one session per user(multiple sessions/multiple "logical" users). We created a couple of Java classes to wrap that functionality. The resources how this can be done can be found here.
Why did we use Hibernate eventually? Using JDBC is more precise, and more flexibile, but the effort to once again map the ResultSet values into objects is, again, the same manual ORM approach.
For example, if I have a GUI that needs to save a Page, first I have to fetch all the Page Articles and then, after I save the Page, update all the Articles FK to that Page. Notice that Im speaking in nouns(objects), and I dont see any other way to wrap the Page/Articles, except using global state. This is the one thing I wouldnt like to see in my application, and we are, after all, using Java, a OO language.
When we already have an ORM mapper that can be configured(forced would be the more precise word to use in this particular example) to process these thing itself, why to go programming it?
Also, we decided to user google Guice - its much faster, typesafe, and could significantly simplify our development/maintence/testing.
I facing problem of database connection in my project in which i used struts. I cant understand that how i manage my database connections. I want my site good in based on accessing becoz it will get million after launch.
And also face heap size problem in that .
I cant understand that how i will manage my architechture.
Plz guide me,if some one have the knowledge .
I want good java architecture with good management of database connection.
I would suggest you to use Hibernate for DB operation.
It is very good ORM tool
There should be 3 modules atleast for your case of architecture.
1)WebApp
2)Service module
3)Database [Hibernate Module]
Spring has some very good facilities to help you manage DB connections. Have a look at part IV of the documentation : http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/spring-data-tier.html
Spring can help you wether you want to do plain JDBC / SQL or if you want to use a more fancy ORM like Hibernate.
If you want to sustain really high load, that's of course just the begining. You will need a lot of profiling, measuring, tweaking ...
You can look into the layered architecture approach. Struts itself is based upon the MVC architectural pattern.
From Wiki, ...In MVC:
Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made.
Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model.
So, you can comeup with you own data access layer that would work underneath your Model; Checkout A Simple Data Access Layer using Hibernate