+ native SQL code
+/- RowMappers to map results to objects
+ flexible enough to fit my requirements
+ no need to use RowMappers
- what about compound data base schemas?
- need to generate entities every time db changes
The main problem with Hibernate is the need to map entities to JSON (or XML maybe). As a result entities "are leaving" the persistent context which may cause a lot of problems (I've already faced then when using GWT, e.g. hibernate session) that may be very harmful and troublesome.
So the question is to use Hibernate and spend a lot of time solving the mentioned problems or to use JDBC which is old but I guess it better fits to requirements. Or maybe another solution that I don't know currently.
You should use a ORM solution. Since you are building a platform for selling products you will have decent number of entities. Hibernate will improve productivity & help bridge the paradigm mismatch between RDBMS & object oriented languages. Also it will make application maintainable. All this will be possible if you have decent understanding of ORM which will help you avoid common pitfalls that people encounter while using ORM.
In terms of issues due to non-availability of persistence context, there are well known patterns/approaches to address this type of issues.
posted 7 years ago
Thanks for the response. I much appreciate it.
Rishi Shehrawat wrote:In terms of issues due to non-availability of persistence context, there are well known patterns/approaches to address this type of issues.
An ORM tool will give you lots of benefits, for JSON, you actually could use Spring REST Web Service on top of Spring MVC and you only will need the Jackson library jar file.
One question about your site, is it a must that you build it from scratch? I mean there are lots of e-commerce products/websites out there to do all the hard work for you. I personally have one myself at a website called Big Commerce, where I set it up with a template, added my products and site all done, no coding.
I also recommend looking at something like Spring Data JPA if you do choose Hibernate, it will help simplify your DAO/Repositories.
In terms of patterns, anytime you have a website where data gets sent to the client, once it is on the client, you aren't managing it, so whether you use JPA/Hibernate or Jdbc code you will still have to know if you are updating, deleting, or inserting data. But that is what is nice about REST is that it fits the CRUD types well with POST, PUT, GET, and DELETE.
The website will be build from scratch, that's not my decision but my boss and accroding to the requirements I'm not sure if there's ready to use product for such case. I won't be a typical web store :]
Will investigate Spring solutions.
A day job? In an office? My worst nightmare! Comfort me tiny ad!