Data access is fundamental to web applications. All non trivial applications and rarely with an exception do have a database and hence a data access layer. SQL has emerged as the de-facto standard to access the database. SQL stands for Structured Query Language and is independent of any programming language. Whether it's .Net, Java, C++ SQL is the prominent way of talking to database. However we are here discussing about Java than let's look more closely on the way it is handled.
In Java the question basically boils down to a choice between JDBC or ORM (hibernate/entity beans). In ORM there are again couple of choices. The most preferred choice is Hibernate but with EJB3.0 (JPA and entity beans), the standard has also embraced the hibernate concepts. In fact
Hibernate supports EJB3.0 also. So the question that we will try to answer is whether JDBC or ORM. Also please understand that ORM uses JDBC internally, but shields the user from this fact and exposed an object oriented way of working with data access code.
Hibernate supports EJB3.0 also. So the question that we will try to answer is whether JDBC or ORM. Also please understand that ORM uses JDBC internally, but shields the user from this fact and exposed an object oriented way of working with data access code.
Again I think there is no black and white approach. The balancing point is usually hinges on performance and maintainability. JDBC are quite good in performance but brings a lot of maintainability issue when the schema changes. ORM framework bring maintainability but at the cost of performance. Though the aspect of performance in ORM framework is more of not using the framework correctly , many times. People have usually adopted a middle ground approach where the basic CRUD is done using ORM tools as it's a productive and maintainable way. However for reporting queries, one resort to plain hand coded SQL. This provides the right mix of performance and maintainability. For writing plain SQL frameworks like Hibernate provide access to low level connection object so you can still use Hibernate as your main mechanism for dealing with database connectivity.
One point of contention that usually comes is that which way is better in performance. Fair question. ORM is a wrapper over JDBC so any day the wrapper would be slower than JDBC, if JDBC is done properly. However there are other considerations to be aware of. Performance is one of the many criteria though a very important one but you also want to consider issues like maintainability and ability to support multiple databases. Also Hibernate supports first level cache as Persistent context so that you do not land up fetching the same record again and again unknowingly. At the end, if you start with JDBC and start providing the multiple features that Hibernate provides you will land up building a framework like Hibernate. Then there will be only people of your team who understands that and soon you might spend a lot of time maintaining that framework rather than focusing on solving business problems.
More About ORM
One point of contention that usually comes is that which way is better in performance. Fair question. ORM is a wrapper over JDBC so any day the wrapper would be slower than JDBC, if JDBC is done properly. However there are other considerations to be aware of. Performance is one of the many criteria though a very important one but you also want to consider issues like maintainability and ability to support multiple databases. Also Hibernate supports first level cache as Persistent context so that you do not land up fetching the same record again and again unknowingly. At the end, if you start with JDBC and start providing the multiple features that Hibernate provides you will land up building a framework like Hibernate. Then there will be only people of your team who understands that and soon you might spend a lot of time maintaining that framework rather than focusing on solving business problems.
More About ORM
No comments:
Post a Comment