Mariya Antony christopher wrote:...is it comfortable for writing CRUD operation code using hibernate
What kind of comfortability you are looking at here...? Are you comparing any other ORM framework or with plain JDBC programming?
Mariya Antony christopher wrote:
Vijitha Kumara wrote:Yes in that case you need to create the mapping files in Hibernate but it might give you a lot less maintenance work and also avoid boilerplate JDBC code.
what do you meant by boilerplate JDBC code?how the problem occurs?...
It's that your are given the opportunity to configure most of them from xml and avoid many other tasks such as creating entities from retrieved rows etc...
The key here is to clearly identify what the requirements of the application are. Speculating or guessing that you will need to actually create 100 tables and also need 100 different types of data object is not productive analysis. The idea that you would need a Java class for every data table in a database is a bit fuzzy and misleading. Aside, Hiberate mappings can be designed to extract from many tables in order to create a single persistent object.
Data requirements should be based on clearly written application requirements and design. If you are attempting to build an application and are starting to design a relational database first, you most likely will end up with a weak application design.
Keep in mind that Hibernate is a powerful, ultra-high performance framework. It is highly unlikely that you can write more efficient code than the Hibernate programmers. This is one of the primary reasons why using Hibernate is a best practice.