Monday, 14 August 2017

MyBatis vs Hibernate 

Persistence solutions compared


FeaturesiBATISHibernateSpring JPA
SimplicityBestGoodGood
Complete ORM solutionAverageBestBest
Adaptability to data model changesGoodAverageAverage
ComplexityBestAverageAverage
Dependence on SQLGoodAverageAverage
PerformanceBestBestN/A *
Portability across different relational databasesAverageBestN/A *
Portability to non-Java platformsBestGoodNot Supported
Community support and documentationAverageGoodGood

HibernateMyBatis
ORM vs persistence frameworkHibernate is object-relation mapping framework (ORM) which maps Java classes to database tables.MyBatis is persistence framework - not ORM. It maps SQL statements to Java methods.
Database schemaHibernate can create database schema according to your Java modelMyBatis does not have such feature
CacheHibernate has first level cache which is impossible to disable. It means that if you query item through ORM and then delete it directly with SQL, it stays in the cache. You can explicitly clear the cache to get the most updated results from database




Optimistic lock management




ORM tools like Hibernate/JPA with the @Version annotation.
MyBatis doesn't support optimistic concurrency control natively
Lazy loadingHibernate will try to load entire object graph except objects which are marked for lazy loading. myBatis will load data according a SQL query. Lazy loading may improve performance but it may cause connection leaks if it used with <property name="hibernate.enable_lazy_load_no_trans" value="true" /> properties
Hibernate Session managementEntities operations like saving, updating or deleting are performed via Hibernate Session. It requires good understanding how to implement proper Hibernate Session management strategy to avoid detached entity passed to persist and other phenomenons related to HibernateSometimes it may take more time trying to understand underlying Hibernate behavior than add a little bit more work and write raw SQL statements for myBatis.
CascadingHibernate provides cascading, orphan removal and other features for object graphs not present in myBatis - to implement them you'll need to write SQL queries explicitly.
QueriesHibernate has multiple options to form query: SQL, HQL, Criteria API. Sometimes it may be suitable to use Criteria API when you have many optional fields in criteria. It would provide more structured approach to form query and maybe avoid related mistakes.In myBatis you'll write almost raw SQL queries

Some more on myBatis and Hibernate -
1. If you're dealing with a "legacy" database schema where you need to write fairly complicated SQL queries then chances are myBatis will work better.
2. HQL (Hibernate Query Language) is another language you'll have to learn and even then you'll probably find cases where you still need to write SQL. What's more, chances are you will at some spend half a day figuring out the right combination of XML, properties, annotations, etc to get Hibernate to generate a SQL query.
3. Hibernate works better if your view is more object-centric. If however you view is more database-centric then myBatis is a much stronger choice.
4. If you're in complete control of your schema and you don't have an extremely high throughput requirement then Hibernate can work quite well. The object model makes for fairly convenient code but at a huge complexity cost

About MyBATIS (iBATIS ):
MyBatis is persistence framework - not ORM. It maps SQL statements to Java methods.
The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the MyBatis data mapper over object relational mapping tools.To use the MyBatis data mapper, you rely on your own objects, XML, and SQL. There is little to learn that you don’t already know. With the MyBatis Data Mapper, you have the full power of both SQL and stored procedures at your fingertips.
1. iBATIS is a persistence framework that provides the benefits of SQL but avoids the complexity of JDBC.
2. iBATIS encourages the direct use of SQL and ensures that all the benefits of SQL are not overridden by the framework itself.
3. Simplicity is iBATIS's greatest advantage, as it provides a simple mapping and API layer that can be used to build data-access code.
4. iBATIS enables the data model and the object model to be independent of each other.

When to use MyBATIS :
1. You need complete control of the SQL.
2. It is also useful when the SQL queries need to be fine-tuned.
3. Your environment is driven by relational data model.
4. You have to work existing and complex schema's.

When Not to Use MyBATIS :
1. iBATIS should not be used when you have full control over both the application and the database design, because in such cases the application could be modified to suit the database, or vice versa.
2. iBATIS is also inappropriate for non-relational databases, because such databases do not support transactions and other key features that iBATIS uses.

About Hibernate :
Hibernate is object-relation mapping framework (ORM) which maps Java classes to database tables.
1. Hibernate is an open source, lightweight object-relational mapping solution.
2. Hibernate includes a very powerful query language called Hibernate Query Language, or HQL.
3. HQL is very similar to SQL, and also defines some additional conventions.
4. HQL also supports many advanced features of pagination and dynamic profiling that SQL has never supported.
5. HQL does not require any explicit joins when working with multiple tables.
6. Hibernate makes object-relational mapping simple by mapping the metadata in an XML file that defines the table in the database that needs to be mapped to a particular class.

When to use Hibernate :
1. Your environment is driven by object model and wants generates SQL automatically.
2. Hibernate is best used to leverage end-to-end OR mapping. It provides a complete ORM solution, but leaves you control over queries.
3. Hibernate is the best option for object-oriented programmers who are less familiar with SQL.


About Java Persistence API :
1. The Java Persistence API is the standard object-relational mapping and persistence management interface for the Java EE 5 platform. As part of the EJB 3 specification effort, it is supported by all major Java vendors.
2. JPA is a POJO-based standard persistence model for ORM. It is part of the EJB 3 specification and replaces entity beans.
3. JPA uses metadata annotations and/or XML descriptor files to configure the mapping between Java objects in the application domain and tables in the relational database.
4. Defines an SQL-like query language, JPQL (Java Persistence Query Language), which is different from EJB-QL (EJB Query Language), the language used by entity beans.
5. Hibernate is one of the most popular frameworks that implements JPA.

When to use JPA :
1. JPA should be used when you need a standard Java-based persistence solution.
2. JPA supports inheritance and polymorphism, both features of object-oriented programming.

When not to use JPA :
1. Caching, which is not clearly defined in JPA but is well supported by Hibernate.
2. JPA is defined to work with relational databases only.
3. If your persistence solution needs to be extended to other types of data stores, like XML databases, then JPA is not the answer to your persistence problem.

Other ORMs:
ActiveJDBC is the implementation of the active record pattern. The library is lightweight and easy to use. Unfortunately, it does not integrate with Spring transaction management, so I had to write some code for it. It's author, Igor Polevoy, reacts really quickly to new requests in GitHub's issue tracker.

Apache Cayenne is an ORM that generates domain objects (DO) from an XML model that can be managed by bundled a GUI application called a modeler. Same as ActiveJDBC, I had to write a custom integration into Spring Transaction Management (STA).

jOOQ is one of the three frameworks that can be chosen on the Spring Initializr page. This means a good integration with Spring. The ORM generates code not only for DOs but also for user-defined types and stored procedures. It still has some flaws, like problems with combining UDTs with POJOs or DAO insert methods that don't return autogenerated primary key values.